# Blueprints

Guided integrations, each one a sequence of real API calls with the samples to run them. Follow a blueprint end to end and you have a working integration rather than a collection of endpoints you've read about.

## Card payments

- [Accept your first payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/accept-your-first-payment.md): Take a card sale over the API against the sandbox, read the result back, then prove your decline handling with an amount the sandbox always refuses. (Full integration; 4 steps, 3 API calls)
- [Authorize now, capture later](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/authorize-now-capture-later.md): Hold the funds when the customer orders, capture them for what you actually shipped, and read back the record that settles. (Full integration; 4 steps, 3 API calls)
- [Refund or void a payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/refund-or-void-a-payment.md): Undo a payment both ways: cancel one before the batch closes, then credit part of another back after it has settled, and read which of the two a transaction will actually accept. (Full integration; 8 steps, 7 API calls)
- [Save a card and charge it later](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/save-a-card-and-charge-it-later.md): Take one card sale, keep a reusable handle to the card it was paid with, charge that handle for a second order without the card number, and retire it when the customer is done with you. (Full integration; 6 steps, 5 API calls)
- [Take a payment with a hosted payment page](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/take-a-payment-with-a-hosted-payment-page.md): Configure a hosted page, open a session for one payment, send the customer to it, then reconcile the result from the webhook rather than from the redirect. (Full integration; 7 steps, 5 API calls)

## ACH payments

- [Accept an ACH payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/accept-an-ach-payment.md): Debit a bank account over the API, understand what an ACH approval promises and what it doesn't, and be ready for the return that can arrive days later. (Full integration; 4 steps, 2 API calls)
- [Simulate an ACH return](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/simulate-an-ach-return.md): Send an ACH sale at an amount the sandbox returns, and read the NACHA return code off the response. (Testing scenario; 2 steps, 1 API call)

## Billing and invoicing

- [Bill a customer on a schedule](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/bill-a-customer-on-a-schedule.md): Charge a new subscriber, keep their card, and put them on a monthly contract the platform bills for you, instead of running the schedule from your own service. (Full integration; 8 steps, 6 API calls)
- [Invoice a customer and get paid](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/invoice-a-customer-and-get-paid.md): Create a customer, write them an invoice, issue it, and record the payment when it arrives, so you know what the platform does at each stage of an invoice's life. (Full integration; 9 steps, 6 API calls)

## Declines and card verification

- [Handle a CVV mismatch](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/test-cvv-mismatch-handling.md): Drive a CVV match, a no-match, and an issuer that can't check, so your integration handles the security code the payer typed rather than assuming it was verified. (Testing scenario; 4 steps, 3 API calls)
- [Simulate a card decline](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/simulate-a-card-decline.md): Send a card sale the sandbox always refuses, and handle the refusal where it actually arrives: in the response body, not as a transport error. (Testing scenario; 2 steps, 1 API call)
- [Test AVS responses](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/test-avs-responses.md): Drive an address match, a mismatch and an unavailable result through the sandbox, so your integration reads the AVS code off the response instead of assuming the address was checked. (Testing scenario; 4 steps, 3 API calls)
- [Trigger a partial approval](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/trigger-a-partial-approval.md): Send a card sale the sandbox approves for less than you asked for, so your integration has to read the authorized amount instead of assuming it. (Testing scenario; 2 steps, 1 API call)

## Webhooks and reliability

- [Receive and verify webhooks](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/receive-and-verify-webhooks.md): Stand up a receiver, register it as a signed destination, subscribe to transaction events, then trigger a sandbox sale and prove the delivery that arrives came from this platform. (Full integration; 7 steps, 5 API calls)
- [Retry a payment without a double charge](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/retry-a-payment-safely.md): Send a payment under a key you chose, ask the platform what became of it, and retry a request you never got an answer to without charging the cardholder twice. (Full integration; 7 steps, 4 API calls)
- [Exercise processor failover](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/exercise-processor-failover.md): Force a processor to report that it didn't process a transaction, and see both of what happens next: a fallback processor approving, and failover running out of processors. (Testing scenario; 5 steps, 2 API calls)
- [Simulate processor latency](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/simulate-processor-latency.md): Make the sandbox processor take its time, then make it answer later than your own client is willing to wait, so your timeout path is something you have run rather than something you have written. (Testing scenario; 3 steps, 2 API calls)

## See also

- [All documentation](https://devportal-simpay-sbx.winkpg.io/llms.txt): the machine-readable index of every public page on this site.