_test.md file that produced the run. No real money moves in any of these runs, and you should point your own copies at a sandbox or test-mode environment.
Run these recipes
Save any recipe below as a file ending in_test.md, change the url to your sandbox checkout, and replace the amounts, test cards, and IDs with values from your own test data. Then run it:
{{test_card}} with --variables-file. See Variables & Context for secrets and Test.md for the file format.
Card checkout
Card checkout is the path most payment changes touch. These recipes cover the happy path, a declined card, a stored card, and a guest card, and each one checks the receipt rather than only the success banner.Hosted checkout session
A hosted checkout page has to charge the amount the order summary shows. This recipe checks the plan and total, pays with a test card, and then checks the receipt for the payment ID, the amount paid, the card, and the succeeded status.hosted-checkout-session_test.md
Declined card recovery
When a shopper’s first card is declined, the second card still has to work on the same page. This recipe pays with a decline test card, checks the inline error, confirms the form is still editable, and retries with a working card.declined-card-recovery_test.md
Stored card reuse
A returning customer paying with a stored card should never see a card number field. This recipe checks that the stored card is preselected, that no card entry is shown, and that the payment result names the stored token.stored-card-reuse_test.md
Guest card payment in a wallet window
Many wallets let shoppers pay by card without an account, and that path is easy to break when the wallet login changes. This recipe opens the wallet window, switches to paying by card as a guest, and checks the payment completes with the guest card.guest-card-payment_test.md
Wallets, redirects, and local methods
Wallets, bank redirects, and local methods add a popup, a second site, or a validation step to checkout. These recipes follow the shopper through that extra step and back.Wallet express checkout
A shopper who reaches the wallet button has already decided to buy, which makes it the worst place for an untested change. This recipe opens the wallet approval window, logs in with a test account, approves the payment, and checks the order completed.express-checkout_test.md
Bank redirect (iDEAL)
Bank redirect methods send the shopper to the bank and back, and the return trip is where the state gets lost. This recipe picks iDEAL and an issuer, approves the payment in the issuer simulator, and checks the result after the redirect.ideal-redirect_test.md
UPI intent and VPA validation
A UPI ID field has to reject malformed and unknown IDs before it accepts a good one. This recipe tries a malformed ID, an unknown ID, and a valid ID in turn, and then pays.upi-intent_test.md
Currency conversion before sending
An international payment has to show the rate, the spread, and the converted amount before the sender confirms. This recipe enters an amount for a recipient in another currency and checks that the same numbers appear on the review screen and the receipt.currency-conversion_test.md
Pay later and instalments
Pay-later and EMI flows show a schedule or a plan table that the customer agrees to. These recipes check those numbers before confirmation, and check the fallback when credit is declined.Pay in 4
A pay-in-4 checkout has to show the full instalment schedule before the shopper confirms. This recipe completes the quick credit check and checks the four payment amounts, their due dates, the total, and the zero interest line before placing the order.pay-in-4_test.md
Credit decision decline
When a pay-later provider declines a shopper, the merchant still has to offer another way to pay. This recipe triggers a decline, checks the decline message, and confirms the shopper is returned to the other payment options.credit-decision-decline_test.md
EMI plan table
EMI should appear only on orders above the threshold, and each tenure has to show the right rate and monthly amount. This recipe checks that a high-value order offers EMI while a low-value one does not, and then checks every row of the plan table.emi-options_test.md
Payment links and invoices
Links and invoices are paid outside the main checkout, often from an email. These recipes check that each one is paid once and that its status changes everywhere it appears.Single-use payment link
A payment link should take one payment and then refuse another. This recipe pays an open link and checks that the badge, the payment banner, and the disabled pay button all show the link as used.payment-link_test.md
Checkout link receipt
A checkout link sent to a customer has to charge the listed amount and send the receipt to the right address. This recipe pays a checkout link and checks the receipt for the payment ID, the item, the total, and the receipt email.checkout-link_test.md
Invoice pay
Paying an invoice has to flip its status on the invoice page and in the invoice list. This recipe opens an unpaid invoice, checks the billing details and amount due, pays it, and checks the paid status in both places.invoice-pay_test.md
Back office and reconciliation
Support and finance teams work from the dashboard, not the checkout. These recipes check that refunds, disputes, lookups, and webhooks agree with the payment the shopper made.Dashboard payment lookup
When a customer questions a charge, support searches the dashboard, and opening the wrong payment sends a refund to the wrong person. This recipe takes a payment, searches the dashboard for its ID, and checks the same ID, amount, and status on the detail page.dashboard-payment-lookup_test.md
Partial refund from the dashboard
A partial refund has to update the payment row and the net sales figure together. This recipe refunds part of a payment from the dashboard and checks the refunded amount, the net amount, the status badge, and the net sales total.refund-from-dashboard_test.md
Dispute filing
A dispute has to create a case with a reference that support can look up later. This recipe opens a transaction, files a dispute with a reason and details, and checks the case reference, reason, and status.dispute-filing_test.md
Webhook status parity
The status a merchant sees on the order page has to match the status the payment provider sent in its notification. This recipe takes a payment, opens the merchant order page, and compares the UI status with the webhook status for the same order.webhook-status-parity_test.md
Next steps
- E-commerce Testing: search, cart, checkout, orders, and store admin
- API Testing: check payment endpoints directly, including SLA gates
- DevTools & Performance Testing: assert on the network calls behind a payment
- Variables & Context: keep test cards and passwords out of your files