Testing Card Payments
Overview
Stitch's test client simulates real acquirer responses so you can verify card-not-present integrations against deterministic outcomes before going live. The cents portion of the transaction amount controls the simulated response. Use the amounts in the tables below to drive approvals, declines, and network-failure scenarios.
All examples use ZAR (R). The cents value drives the outcome; the rand portion is free for you to choose.
Test approvals
| Amount | Result | Notes |
|---|---|---|
R10.00 | Approved | Standard approval. Use this as your default. |
R10.08 | Approved (please sign) | Tests the signature-required flow. |
R10.11 | Approved (VIP) | Tests VIP cardholder handling. |
R10.16 | Approved (update track 3) | Tests the update-track-3 acknowledgement. |
Test declines
These amounts return common decline responses. Use them to verify that your integration surfaces the correct user-facing messaging and handles each scenario.
| Amount | Result |
|---|---|
R10.01 | Refer to issuer |
R10.05 | Do not honour |
R10.12 | Invalid transaction |
R10.14 | Invalid card number |
R10.41 | Lost card |
R10.43 | Stolen card |
R10.51 | Insufficient funds |
R10.54 | Expired card |
R10.57 | Not permitted to cardholder |
R10.61 | Exceeds withdrawal amount |
R10.91 | Issuer unavailable |
The rand portion of the amount does not affect the response. R10.51, R250.51, and R3500.51 all return insufficient_funds. Pick whichever rand value suits your test scenario.
Network failure simulation
To test how your integration handles upstream unavailability, submit an e-commerce transaction with the exact amount R503.00. The platform responds with HTTP 503 Service Unavailable, simulating an acquirer that is temporarily unreachable. Use this to exercise your retry, fallback, and error-handling paths.