Testing

What crosses the wire

• Where it sits

  In the same place your production payment call sits. You change the credential and the card number; the endpoints, the request bodies and the response shapes do not change, which is what makes the exercise transferable.

• What you send

  A normal payment request carrying a documented test card. The reference lists each card, the brand it emulates and the outcome it produces, including which ones require an authentication step to complete.

• What comes back

  The same response your integration will see on production, followed by the same lifecycle events. Assert on the state and the typed code, not on the HTTP status alone.

When to use it

• Before go-live

  Every decline path, the 3-D Secure challenge and at least one refund should be walked once, deliberately, rather than discovered by a customer.

• In CI

  Sandbox runs make payment logic regression-testable rather than manually verified, and they catch the change that quietly stopped handling a code.

• After any dependency upgrade

  An SDK bump, a framework change or new middleware can break webhook signature verification without touching a line of your own payment code.

How to implement Testing

What fails, and how you find out

• Only the happy path is covered

  An integration that has never seen a decline will ship one. The approval card proves connectivity; the decline cards prove the application actually handles the outcome your customers will hit most often.

• Tests that assert on message text

  Message wording is not part of the contract and will change. A test pinned to it fails on a copy edit and passes on a genuine regression, which is the worst of both.

• Webhook handling never exercised

  If tests only call the API and read the response, the handler that fulfils orders is untested. Drive at least one test through the event, including a deliberate redelivery.

• Sandbox timings copied into production assumptions

  Settlement in sandbox is compressed. Code that assumes a funded event follows a capture within minutes will sit idle on production, where it follows your funding schedule.

Sandbox versus production

• The outcome is deterministic

  No issuer is contacted. A card that declines for insufficient funds does so on every attempt, at any hour, which is the property that makes payment logic safe to assert on in CI.

• Authentication is simulated, not skipped

  The 3-D Secure step still runs; what changes is that a test card decides whether it passes without friction or presents a challenge, so both branches are reachable on demand.

• Nothing settles for real

  Sandbox deposits, fees and batch records exist so reconciliation code can be written against them, but they are illustrative. Your actual rate and funding schedule come from your account, not from a sandbox response.