# Choose an integration method Three questions about where your customers enter their card details, and what that means for the PCI evidence you have to produce every year. 4 questions, 6 outcomes ## Where does the payment happen? https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/where-does-the-payment-happen.md Card-present payments and online payments are scoped differently, so this is the fork that decides everything after it. **Choose one** - Online, or over the phone. The card details are typed into a screen rather than read from the card. Leads to: Who renders the fields your customer types the card into?. - In person, with the card at the counter. A reader captures the card, whether by chip, contactless, or swipe. Leads to: Take the payment on a card reader. ### Who renders the fields your customer types the card into? https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/who-renders-the-card-fields.md This is the question your assessor asks first, because it decides whether the card number ever reaches a system you are responsible for. **Choose one** - A payment page this platform hosts. Your checkout redirects to it, or embeds it in an iframe. Leads to: Will you charge the same customer again when they are not there?. - My own checkout, using payment fields this platform supplies. You control the layout. The fields themselves are served by us. Leads to: Will you charge the same customer again when they are not there?. - My own systems, which receive the card number. Your servers hold the card number before they send it to us. Leads to: Call the API directly. #### Will you charge the same customer again when they are not there? https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/hosted-page-repeat-payments.md Subscriptions, instalments, saved cards at a later checkout, and any charge your system starts on its own all count. Taking the card again each time does not. **Choose one** - No. Each payment starts with the customer at the checkout. Leads to: Use a hosted payment page. - Yes. I need to store the card and charge it later. You store a token this platform issues. The card number stays with us. Leads to: Use a hosted payment page, and save the card. ##### Use a hosted payment page https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/hosted-payment-page.md Your checkout hands off to a payment page this platform serves, and we hand the result back to you. **What to build** Create a hosted payment page session from your server, send the customer to the link it returns, and confirm the result from the webhook rather than from the browser redirect. This is the smallest amount of code of the three online methods and the smallest annual evidence burden. **What this means for PCI** Typically eligible for **SAQ A**. The card fields are served and submitted by a page this platform hosts, so no system of yours transmits, processes, or stores the card number. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - You style the page with your own branding, but the layout is ours rather than yours. - Confirm the payment from the webhook. A customer who closes the tab after paying never reaches your redirect. **Where to go next** - [Quickstart: hosted payment page](https://devportal-simpay-sbx.winkpg.io/docs/guides/quickstart-hosted-payment-page.md) - [Blueprint: 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) - [Embedding the page in an iframe](https://devportal-simpay-sbx.winkpg.io/docs/guides/hpp-iframe-integration.md) ##### Use a hosted payment page, and save the card https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/hosted-payment-page-with-saved-cards.md The same hosted page, asked to store the card so you can charge it again without the customer present. **What to build** Take the first payment through a hosted payment page and ask it to save the card. You store the token we return, not the card number, and every later charge is an API call against that token. Keep the customer's consent to store the card on record: the card networks require it, and you are the one who collected it. **What this means for PCI** Typically eligible for **SAQ A**. Saving the card does not widen your scope, because the card number is captured by the hosted page and what you keep is a token. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - Charging a stored card is a different request from the first payment, and it has to say why the charge is being made. - Give the customer a way to remove a stored card. A token you cannot delete outlives the consent that justified it. **Where to go next** - [Quickstart: hosted payment page](https://devportal-simpay-sbx.winkpg.io/docs/guides/quickstart-hosted-payment-page.md) - [Blueprint: save a card and charge it later](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/save-a-card-and-charge-it-later.md) - [Reusing saved cards](https://devportal-simpay-sbx.winkpg.io/docs/guides/reusing-saved-cards.md) #### Will you charge the same customer again when they are not there? https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/embedded-fields-repeat-payments.md Subscriptions, instalments, saved cards at a later checkout, and any charge your system starts on its own all count. Taking the card again each time does not. **Choose one** - No. Each payment starts with the customer at the checkout. Leads to: Use embedded payment fields. - Yes. I need to store the card and charge it later. You store a token this platform issues. The card number stays with us. Leads to: Use embedded payment fields, and save the card. ##### Use embedded payment fields https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/embedded-payment-fields.md Your checkout, your layout, with the card fields themselves served by this platform. **What to build** Load the embedded payments SDK into your checkout and let it render the card fields. The customer stays on your page and never sees a redirect, and the SDK exchanges the card details for a token your server charges. **What this means for PCI** Typically eligible for **SAQ A-EP**. Your page does not touch the card number, but it does control the page the fields are loaded into, which is what makes the questionnaire longer than a hosted page's. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - The scope covers the whole checkout page, including any third-party script you load beside the fields. - You own the checkout layout, so you also own its accessibility and its behaviour on a small screen. **Where to go next** - [Quickstart: embedded payments SDK](https://devportal-simpay-sbx.winkpg.io/docs/guides/quickstart-embedded-payments-sdk.md) - [Embedded payments compared with direct card scripts](https://devportal-simpay-sbx.winkpg.io/docs/guides/embedded-payments-vs-direct-card-scripts.md) - [Blueprint: accept your first payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/accept-your-first-payment.md) ##### Use embedded payment fields, and save the card https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/embedded-payment-fields-with-saved-cards.md The same embedded fields, asked to store the card so you can charge it again without the customer present. **What to build** Render the card fields with the embedded payments SDK and ask it to store the card against a customer. You keep the token, not the card number, and every later charge is an API call against that token. Keep the customer's consent to store the card on record. **What this means for PCI** Typically eligible for **SAQ A-EP**. Storing the card does not widen your scope beyond what the embedded fields already put in it, because what you keep is a token. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - Charging a stored card is a different request from the first payment, and it has to say why the charge is being made. - Give the customer a way to remove a stored card. A token you cannot delete outlives the consent that justified it. **Where to go next** - [Quickstart: embedded payments SDK](https://devportal-simpay-sbx.winkpg.io/docs/guides/quickstart-embedded-payments-sdk.md) - [Blueprint: save a card and charge it later](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/save-a-card-and-charge-it-later.md) - [Reusing saved cards](https://devportal-simpay-sbx.winkpg.io/docs/guides/reusing-saved-cards.md) #### Call the API directly https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/direct-api.md Your systems receive the card number and send it to this platform themselves. **What to build** Post the card details to the payments API from your server. Choose this only when something about your product genuinely requires it, such as a call centre taking card numbers by phone or a checkout you cannot load our fields into. It is the most work to build and by far the most to prove every year. **What this means for PCI** Typically eligible for **SAQ D**. Your systems transmit the card number, so everything they touch is in scope. Above a certain volume, an on-site assessment by a QSA takes the place of the questionnaire. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - Every system the card number passes through is in scope, including logs, queues, and backups. - Ask whether one of the other two methods covers the case before committing to this one. Moving off it later means rebuilding the checkout. **Where to go next** - [Quickstart: direct API](https://devportal-simpay-sbx.winkpg.io/docs/guides/quickstart-direct-api.md) - [Getting started with the API](https://devportal-simpay-sbx.winkpg.io/docs/guides/api-getting-started.md) - [Blueprint: accept your first payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/accept-your-first-payment.md) ### Take the payment on a card reader https://devportal-simpay-sbx.winkpg.io/docs/decide/integration-method/card-present-terminal.md The card is present, so the reader captures it and your software never sees the card number. **What to build** Talk to your account team about which readers this instance supports before you build anything. The reader decides your scope, so choosing it is the first decision rather than a detail at the end. Your own integration then works the same way the online ones do: your server calls the API and reads the result. **What this means for PCI** Typically eligible for **SAQ B-IP or SAQ P2PE**. SAQ P2PE is typically the one when the reader is part of a validated point-to-point encryption solution, and SAQ B-IP when it is not. Which one applies depends on the reader rather than on your software. This is guidance rather than a compliance determination. Which questionnaire you are eligible for depends on your full environment, so confirm it with your QSA or your acquirer before you rely on it. **Worth knowing** - A reader that encrypts to a validated solution is the shortest annual questionnaire available for a card-present merchant. - If you also take payments online, that half is scoped separately. Walk this guide again for it. **Where to go next** - [Getting started with the API](https://devportal-simpay-sbx.winkpg.io/docs/guides/api-getting-started.md) - [Blueprint: accept your first payment](https://devportal-simpay-sbx.winkpg.io/docs/blueprints/accept-your-first-payment.md) - [Decision guides](https://devportal-simpay-sbx.winkpg.io/docs/decide.md): every decision guide this instance publishes. ## See also - [All documentation](https://devportal-simpay-sbx.winkpg.io/llms.txt): the machine-readable index of every public page on this site.