# Choose what to test in the sandbox Which sandbox scenario proves the part of your integration you're about to ship, and the blueprint that runs it. 3 questions, 9 outcomes ## What are you testing next? https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/what-you-are-testing-next.md Every scenario here runs on a sandbox merchant and reaches no card network. Pick the behavior you need to see your code handle. **Choose one** - A payment going through, start to finish. Your first request, or a check that nothing basic is broken. Leads to: Run a payment end to end. - What my code does when a payment is refused or comes back. Declines, partial approvals, verification results, and ACH returns. Leads to: Which refusal do you need to see?. - What my code does when a processor is slow or unavailable. Timeouts, and the platform failing over to another processor. Leads to: What does the processor do?. - The events my systems receive after a payment. Webhook deliveries, and proving they came from this platform. Leads to: Receive and verify a webhook. - How a particular kind of card is classified. Debit, prepaid, commercial, government, healthcare, or EBT. Leads to: Run the classification test cards. ### Run a payment end to end https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/run-a-payment-end-to-end.md Create a sale, read it back, and make the sandbox decline you once, all from one blueprint. **What to build** Run the first-payment blueprint against a sandbox merchant. It creates a card sale at an amount the sandbox always approves, reads the transaction back, and then sends a declining amount so you see both shapes of response before you write code against either. **Worth knowing** - The sandbox picks the result from the amount, the billing ZIP, and the security code, not from the card number. Use the blueprint's amounts rather than inventing your own. - Send an idempotency key from your first request, so it's already in place when you test retries. **Where to go next** - [Accept your first payment](https://devportal.qa.winkpg.io/docs/blueprints/accept-your-first-payment.md) - [Direct API quickstart](https://devportal.qa.winkpg.io/docs/guides/quickstart-direct-api.md) - [Getting started with the API](https://devportal.qa.winkpg.io/docs/guides/api-getting-started.md) ### Which refusal do you need to see? https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/which-refusal.md Each one arrives in the response body, not as a transport error, and each one is read from a different field. **Choose one** - A card decline. The issuer refuses the payment outright. Leads to: Simulate a decline. - An approval for less than I asked for. Common on prepaid and debit cards with a low balance. Leads to: Trigger a partial approval. - An address or security code that doesn't match. The payment may still be approved, and your code has to notice. Leads to: Drive address and security code results. - A bank debit that comes back. An ACH return, which arrives after the debit looked successful. Leads to: Simulate an ACH return. #### Simulate a decline https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/simulate-a-decline.md Send a sale the sandbox always refuses, and handle the refusal where it arrives: in the response body. **What to build** Run the card decline blueprint. Branch on resultCode and declineReasonCode, never on the description text, and decide from the reason code whether the payment is worth retrying. **Worth knowing** - A decline is an HTTP success carrying a refused transaction. Code that only checks the status code treats it as an approval. **Where to go next** - [Simulate a card decline](https://devportal.qa.winkpg.io/docs/blueprints/simulate-a-card-decline.md) - [Understanding declines and rejections](https://devportal.qa.winkpg.io/docs/guides/understanding-declines-and-rejections.md) #### Trigger a partial approval https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/trigger-a-partial-approval.md Send a sale the sandbox approves for less than you asked for, so your code has to read the authorized amount instead of assuming it. **What to build** Run the partial approval blueprint, and decide what your checkout does with the shortfall: collect the rest on another payment method, or cancel the partial approval and ask for a different card. **Worth knowing** - A partial approval that nobody acknowledges is voided automatically. Treat it as a state your checkout has to resolve, not as an approval. **Where to go next** - [Trigger a partial approval](https://devportal.qa.winkpg.io/docs/blueprints/trigger-a-partial-approval.md) - [Transaction lifecycle and settlement](https://devportal.qa.winkpg.io/docs/guides/transaction-lifecycle-and-settlement.md) #### Drive address and security code results https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/drive-address-and-security-code-results.md Make the sandbox return a match, a mismatch, and an issuer that can't check, for the address and for the security code. **What to build** Run the AVS blueprint and the CVV blueprint. Each sends the three cases side by side, so you can compare the codes your integration reads and confirm it doesn't assume a check passed because the payment was approved. **Worth knowing** - A merchant's own verification rules can refuse an approved payment. That arrives as a policy rejection, which is never retried unchanged. **Where to go next** - [Test AVS responses](https://devportal.qa.winkpg.io/docs/blueprints/test-avs-responses.md) - [Handle a CVV mismatch](https://devportal.qa.winkpg.io/docs/blueprints/test-cvv-mismatch-handling.md) - [Understanding declines and rejections](https://devportal.qa.winkpg.io/docs/guides/understanding-declines-and-rejections.md) #### Simulate an ACH return https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/simulate-an-ach-return.md Send an ACH sale at an amount the sandbox returns, without waiting days for a real bank to do it. **What to build** Run the ACH return blueprint, and read the return code off the transaction. Make sure your systems mark the order unpaid rather than issuing a refund: the bank already pulled the money back. **Worth knowing** - Transaction.Settled never fires for ACH. Test against Transaction.AchStatusChanged and Transaction.Returned. **Where to go next** - [Simulate an ACH return](https://devportal.qa.winkpg.io/docs/blueprints/simulate-an-ach-return.md) - [ACH payments](https://devportal.qa.winkpg.io/docs/guides/ach-payments.md) ### What does the processor do? https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/what-the-processor-does.md A slow answer tests your timeout. A processor that won't process tests the platform's failover, and what reaches you when it runs out of options. **Choose one** - It answers, but slowly. Slower than your own client is willing to wait. Leads to: Simulate a slow processor. - It refuses to process the payment. The merchant has another processor to fall back to, or doesn't. Leads to: Exercise failover. #### Simulate a slow processor https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/simulate-a-slow-processor.md Make the sandbox processor take its time, then make it answer later than your own client will wait. **What to build** Run the processor latency blueprint, then the safe retry blueprint. The first proves your timeout fires; the second proves what you do next doesn't charge the customer twice. **Worth knowing** - A timeout in your client doesn't mean the payment failed. It may have completed, so look it up by its idempotency key before you resend. **Where to go next** - [Simulate processor latency](https://devportal.qa.winkpg.io/docs/blueprints/simulate-processor-latency.md) - [Retry a payment without a double charge](https://devportal.qa.winkpg.io/docs/blueprints/retry-a-payment-safely.md) #### Exercise failover https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/exercise-failover.md Watch a fallback processor approve, and watch what reaches you when failover runs out of processors. **What to build** Run the processor failover blueprint. It gives the sandbox merchant a second processor profile, makes the first refuse to process, and runs both outcomes. The exhausted case is the one to write code for. **Worth knowing** - Only a processor answering that it didn't process the payment triggers failover, and it happens once. A decline, a timeout, or a transport failure is final, because it's ambiguous about whether money moved. **Where to go next** - [Exercise processor failover](https://devportal.qa.winkpg.io/docs/blueprints/exercise-processor-failover.md) - [Processor routing and failover](https://devportal.qa.winkpg.io/docs/guides/processor-routing-and-failover.md) ### Receive and verify a webhook https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/receive-and-verify-a-webhook.md Stand up a receiver, subscribe it to transaction events, and prove the delivery that arrives came from this platform. **What to build** Run the webhooks blueprint. It registers your endpoint as a signed destination, sends a test delivery, subscribes to the transaction events, and triggers a sandbox sale, so you see a real delivery and verify its signature. **Worth knowing** - Delivery is at least once. Test that a repeated event id is ignored, not applied twice. - Acknowledge within five seconds and process afterward, because a slow acknowledgement is retried. **Where to go next** - [Receive and verify webhooks](https://devportal.qa.winkpg.io/docs/blueprints/receive-and-verify-webhooks.md) - [Webhooks quickstart](https://devportal.qa.winkpg.io/docs/guides/quickstart-webhooks.md) - [Webhook integration](https://devportal.qa.winkpg.io/docs/guides/webhook-integration.md) ### Run the classification test cards https://devportal.qa.winkpg.io/docs/decide/choose-what-to-test/run-the-classification-test-cards.md Eight sandbox test cards each classify as something specific, so you can see how the platform labels a card before a real one arrives. **What to build** Work through the scenario for the card types your merchants take. Each one gives the request to send and the classification to expect in the response's card data. The classification comes from the whole card number, so send the number exactly as published. **Worth knowing** - The card decides the classification, not the outcome. Approval and decline still come from the amount, except on the EBT card, which takes no amount trigger. **Where to go next** - [Sandbox test cards](https://devportal.qa.winkpg.io/docs/guides/sandbox-test-cards.md) - [Decision guides](https://devportal.qa.winkpg.io/docs/decide.md): every decision guide this instance publishes. ## See also - [All documentation](https://devportal.qa.winkpg.io/llms.txt): the machine-readable index of every public page on this site.