Payment Testing Checklist for QA Teams

Payment bugs are rarely “cosmetic.” They create double charges, silent failures, reconciliation debt, and support queues. A payment testing checklist keeps release conversations concrete when finance, eng, and QA share different vocabularies.

This is a risk-oriented checklist for card and wallet flows via a PSP (for example Stripe-like processors). It complements general how to write QA test cases guidance and pairs with cart coverage in shopping cart test cases.

Ground rules before you test payments

1. Never use real customer cards in shared docs or repositories.
2. Prefer PSP test numbers and test mode keys in non-prod.
3. Separate UI checkout, API intents, and webhook settlement in your plan—they fail differently.
4. Involve finance early on refund, tax, and ledger expectations.
5. Record which environment maps to which PSP account; mix-ups cause false confidence.

Pre-release environment checklist

Happy-path payment checklist

Card success

• Customer can complete checkout with a valid test card
• Order/payment status becomes paid/succeeded in-app
• PSP dashboard shows matching amount/currency
• Receipt/confirmation email sent once
• Inventory/reservation decremented once
• Customer can view order history for the purchase

Wallet / redirect methods (if offered)

• Redirect/return URL succeeds
• Cancel at wallet returns user safely without marking paid
• Duplicate return callbacks do not double-fulfill

Saved payment methods (if offered)

• Customer can pay with a previously saved method
• Removing a method prevents future charges
• Default method selection behaves as labeled

Failure and decline checklist

Use edge case testing habits here—payments are full of “almost succeeded” states.

Assert server-side status, not only a green UI toast. UI can lie when webhooks lag.

Webhooks and asynchronous settlement

Signature verification

• Valid signature accepted
• Invalid signature rejected with no state change
• Replay of an old event does not re-fulfill (idempotent handlers)

Out-of-order events

• payment_failed after UI timeout still ends unpaid
• Late payment_succeeded after user refreshed still fulfills exactly once

Handler failure recovery

• Transient 500 from your webhook handler can be retried by PSP without double side effects

// Conceptual idempotency guard
if (alreadyProcessed(event.id)) return 200;
process(event);
markProcessed(event.id);

Amounts, currency, and tax

• Minor units correct (cents vs whole currency)
• Multi-currency display matches charge currency
• Discounts applied once; cannot stack beyond rules
• Tax calculation matches finance rules for region fixture
• Shipping changes update authorization amount before capture (if auth/capture split)

Auth/capture, refunds, and cancellations

Auth then capture

• Uncaptured auth expires per PSP rules without fulfillment confusion
• Partial capture amounts ledger correctly
• Cancelled auth never becomes “paid” in-app

Refunds

• Full refund updates order and customer-visible status
• Partial refund allowed only when business rules say so
• Refund webhooks reconcile to the same final state as admin UI actions
• Inventory restock policy executed as designed (or explicitly skipped)

Chargebacks (process readiness)

Even if you cannot fully simulate chargebacks in every env:

• Support runbook exists
• Order state for dispute is represented or linked to PSP

Regional and alternative payment methods

Card testing alone misses a growing share of real transactions. Adapt this table to the methods you actually support.

Expect: each method has its own success, decline, and timeout case—do not assume card-shaped assertions transfer cleanly to delayed-settlement methods.

Coupons, gift cards, and store credit interacting with payment

Discounting logic frequently lives in the cart, but the payment layer still needs cases where money and non-money instruments combine.

This intersection is where support tickets about "the numbers don't add up" usually originate. Treat it as its own scenario, not an afterthought of standard checkout.

Subscription and recurring billing checklist

One-time checkout rules do not automatically cover subscriptions. Keep this as an addition, not a replacement, for recurring products.

• Trial start does not charge until trial ends (or charges the documented amount immediately, whichever is the real design)
• Trial-to-paid conversion charges exactly once
• Renewal failure triggers dunning per the documented retry schedule
• Mid-cycle plan upgrade prorates correctly; downgrade timing matches policy (immediate vs end-of-cycle)
• Cancel-at-period-end still grants access until the period ends
• Immediate cancellation stops future renewal without altering a completed past charge
• Dunning emails stop the moment payment succeeds, even mid-retry-sequence

Security and PCI-adjacent checks

QA does not “certify PCI,” but you can catch reckless design:

• Full PAN never appears in logs, URLs, or your DB (token/last4 only)
• Admin screens mask card data
• XSS in billing name/address fields does not execute in admin tools
• CSRF protections present on state-changing billing posts if cookie session based

Marketplace and split-payment scenarios

Multi-vendor or marketplace products add a payout dimension most single-merchant checklists skip entirely.

Test this with at least two vendors and a partial refund in the same scenario—single-vendor happy paths hide almost all of the interesting payout bugs.

PSP outage and fallback behavior

Payment providers do have incidents. A checklist that assumes 100% PSP uptime leaves a real failure mode untested.

• Timeout to PSP during payment creation shows a retry-safe error, not a false "payment failed"
• Duplicate submit during a slow PSP response does not create two charge attempts
• If a secondary PSP or fallback exists, failover does not double-process an in-flight payment
• Customer-facing error during an outage includes a support path, not a raw gateway error string
• Incident runbook defines who confirms charge status directly with the PSP before refunding blind

Receipts, invoices, and statement descriptors

Small details here generate disproportionate support volume.

Reconciliation checklist for QA + finance

Run a short reconciliation sample before major payment launches—not only UI demos.

Finance-facing dashboards and exports

QA sometimes assumes finance tooling is "just reporting" and skips it. A wrong dashboard number during a launch week erodes trust as fast as a broken checkout.

• Revenue dashboard total matches a manual sum of successful charges for the same window
• Refunds reduce the reported total in the same period they were issued, not silently deferred
• Currency conversion in aggregate reports uses a documented, consistent rate source
• CSV export used for accounting matches the numbers shown in the UI dashboard for the same filter

Automation strategy

Automate:

• Intent creation API responses
• Webhook signature unit/integration tests
• Idempotent fulfill guards

Keep manual:

• 3DS vendor UI quirks
• Wallet redirect UX polish
• Brand-new PSP sandbox surprises

Mark flaky sandbox behaviors in suite notes so CI noise does not train people to ignore red builds.

Suggested smoke set (pre-prod deploy)

1. One successful card payment end-to-end
2. One hard decline path
3. One webhook signature failure
4. One refund (full)
5. One duplicate webhook delivery

Expand for Deep coverage when changing capture models or tax engines. Plans that affect assisted generation volume are on Pricing; integration docs: Docs.

Capture models and delayed fulfillment

Not every merchant captures immediately. When your product uses auth-then-capture or ships-then-capture:

• Authorization succeeds without marking the order as fully paid if that is incorrect in your domain language
• Capture failure after successful auth surfaces a supportable state (not “paid” with no goods plan)
• Partial shipment captures match ledger lines finance expects
• Void/cancel before capture never triggers fulfillment emails that claim payment completed

Write the state machine into suite notes. Ambiguous words like “paid,” “authorized,” and “settled” cause false passes when UI labels disagree with PSP status.

Statement descriptors and customer recognition

Customers dispute what they do not recognize:

• Soft descriptor matches brand policy in test mode
• Receipt shows order reference support can search
• Failed payments do not send “thanks for your purchase” mail

Pair this with cart snapshot checks from the shopping-cart suite so the charged amount equals what the shopper last confirmed.

FAQ

Can we test payments only in the PSP dashboard?

No. Dashboard success without your fulfillment logic still ships broken checkout.

How do we avoid double-charge bugs in tests?

Assert idempotency keys, disable double-submit in UI, and replay webhooks deliberately in staging.

Should QA own tax calculation correctness?

QA verifies implementation against finance-provided matrices. Finance owns the rules.

What about subscriptions?

Add a separate checklist: trial start, renewal success/fail, proration, cancel-at-period-end, dunning. Do not overload one-time checkout cases.

Do we need to test every regional payment method before every release?

No. Run the full regional matrix before launches that touch checkout or the PSP integration; keep one representative alternative method in the regular smoke set so drift is caught sooner.

How do we test marketplace payouts without real vendor bank accounts?

Use the PSP's connected-account test mode if it offers one. Assert the payout calculation and hold state in your own system rather than waiting on real bank transfers to confirm correctness.

Final checklist

• Test mode only; no live secrets in QA materials
• Happy path + decline + 3DS abandon covered as applicable
• Webhook signatures and replays verified
• Amounts/currency/tax checked against fixtures
• Refunds and auth/capture rules exercised
• PAN never logged or stored raw
• Reconciliation sample planned for launches
• Automation covers handlers; manual covers redirects
• Cart and payment suites cross-linked without duplicating every assertion
• Support runbooks exist for disputes and PSP outages
• Regional/alternative payment methods have their own success and decline cases
• Gift card, store credit, and coupon combinations verified against payment totals
• Subscription proration and dunning covered as their own checklist
• Marketplace payout splits verified with a partial refund scenario

CTA — structure payment stories before sandbox day

Payment epics often arrive as sticky notes (“support 3DS”). Convert acceptance criteria into structured cases with QA Workflow Assistant, then map each case onto this checklist so webhook and ledger gaps are visible before demo day. Keep PSP credentials and test cards in your vault—not in prompts. See Docs for product setup.