Skip to main content

Payment Change Checklist

If a change can break auth rate, it needs sign-off from whoever owns payments or fraud.

Checkout is where money happens. Changes that seem minor can tank conversion, trigger fraud rules, or create disputes. Test before you ship.

Minimum for Solo Operators

Run at least these tests before you ship any checkout change:

  • One successful card payment
  • One forced decline (use test card or wrong CVV)
  • One refund
  • Confirmation email renders correctly

Pre-Deploy Checks​

For Any Checkout Change​

  • Payment flow works end-to-end in staging
  • Successful transaction creates correct order
  • Declined transaction shows appropriate error
  • Refund flow works
  • Confirmation emails send and render correctly
  • Transaction appears in processor dashboard
  • Amount matches order total (including tax, shipping)

For Payment Method Changes​

Adding or removing payment methods:

  • New method enabled in processor dashboard
  • Fallback works if new method fails
  • Currency handling correct
  • Mobile experience tested
  • Fraud rules updated if needed (different signals for different methods)

For Fraud Rule Changes​

  • Rule tested against historical transactions
  • False positive estimate acceptable
  • Monitoring in place for first 24-48 hours
  • Rollback plan documented

If you're under $1M/year in volume: Don't push more than one new rule a month. Always review every single block manually for the first day.

For Processor Changes​

Switching processors or adding failover:

  • BIN routing tested (especially for international cards)
  • Billing descriptor matches old processor
  • Webhook/notification endpoints updated
  • Subscription migrations planned
  • Old processor stays active for chargebacks
  • Auth rates monitored closely first 2 weeks

Common A/B Test Traps​

A/B testing checkout is high-stakes. Watch for:

Auth rate differences: Test variant might have lower auth rate that wipes out conversion gains. Always measure auth rate, not just conversion.

Fraud signal changes: Moving fields around, changing device fingerprint placement, or adding new inputs can affect fraud scoring. Check with your fraud tool.

Mobile vs desktop divergence: Payment flows often break differently on mobile. Test both.

Timing issues: Checkout A/B tests need longer to reach significance because of:

  • Chargebacks that appear 30+ days later
  • Subscription renewal effects
  • Fraud that takes time to surface

The trap: Declaring a winner based on immediate conversion, then discovering 6 weeks later that the "winner" had 2x the chargebacks.

For Agencies and Contractors​

If someone else is touching your checkout:

Before They Start​

  • Define exactly what they can and cannot change
  • Require staging deployment first
  • Require your sign-off before production
  • Document rollback procedure

Specific Restrictions​

  • No changes to fraud parameters without explicit approval
  • No changes to billing descriptor without testing
  • No removal of security features (CVV, 3DS, etc.)
  • No direct database access to payment tables

After They Deploy​

  • You (not they) verify payment flow works
  • Monitor auth rate for 48 hours
  • Check processor dashboard for anomalies

Post-Deploy Monitoring​

First Hour​

  • Auth rate within normal range
  • No error spikes in logs
  • Successful transactions appearing

First Day​

  • Auth rate stable
  • No unusual decline patterns
  • Fraud queue not spiking
  • Customer support not getting payment complaints

First Week​

  • Auth rate trend normal
  • No unexpected chargebacks appearing
  • Processor hasn't flagged anything

Rollback Triggers​

Roll back immediately if:

  • Auth rate drops more than 5% without explanation
  • Error rate on checkout exceeds 2%
  • Fraud queue triples without traffic increase
  • Customers report payment failures
  • Processor contacts you about anomalies

Don't wait to investigate. Roll back first, then figure out what happened.

Where This Breaks​

"Unrelated" changes: The footer update that accidentally broke a JavaScript dependency that affected the payment form. Always test checkout, even for "unrelated" deploys.

Third-party script updates: Analytics, chat widgets, and other scripts can conflict with payment iframes. If a third-party updates their script, test checkout.

CDN and caching: Payment pages should generally not be cached, but misconfigurations happen. Stale payment tokens cause confusing failures.

Test mode leakage: Making a change in test mode and accidentally pushing test credentials to production. Use separate API keys and enforce at the environment level.

Testing Card Numbers​

Use your processor's test cards. Common examples:

Card NumberResult
4242 4242 4242 4242Success
4000 0000 0000 0002Decline
4000 0000 0000 9995Insufficient funds
4000 0000 0000 32203DS required

Check your processor's documentation for their specific test cards. These are Stripe examples.

Next Steps​

Making a checkout change?

  1. Run pre-deploy checks - Payment flow, errors, confirmation
  2. Test with test cards - Success, decline, 3DS scenarios
  3. Set up post-deploy monitoring - Auth rate, errors, queue

Changing fraud rules?

  1. Follow fraud rule checklist - Backtest, estimate FP, monitor
  2. Test against historical transactions - Before deploying
  3. Set rollback triggers - Know when to revert

Switching processors?

  1. Complete processor checklist - BIN routing, webhooks, descriptors
  2. Plan parallel running - Keep old active for chargebacks
  3. Monitor first 2 weeks - Auth rates closely