Choosing an integration

Widget or API: which one fits your situation, and what each means for PCI scope.

PayChoice offers two ways to take a payment. Both create the same charge, both deliver the outcome through the same webhook, and both can store a payment method as a token for later. The difference is who handles the card or bank details.

	PayChoice Widget	Banking API
Where the customer enters details	A PayChoice-hosted page in an iframe on your site	Your own form
Card and bank data on your servers	Never	Yes, in transit
PCI DSS scope	Minimal (SAQ A-style)	Full (you handle cardholder data)
Branding	Fonts, colours, logo via Brand settings	Entirely yours
Payment methods	Card and bank, chosen by the customer	Card, bank or a stored token, chosen by you
Best for	Checkout pages, booking forms, invoices, anywhere a customer pays once	Server-to-server charging, stored tokens, systems with an existing compliant form

If you’re not sure

Start with the Widget. It gets you to a working checkout in an afternoon, and nothing stops you adding API charges later — for example, charging a token the Widget’s Create Token page captured.

What both have in common

• You supply a reference (the Widget calls it MerchantReference). It’s echoed on the charge and in every webhook, so make it something you can match to your own records.
• Card charges are approved or declined immediately. Bank charges come back as Processing and settle over up to three business days.
• The final outcome always arrives by webhook. Treat anything shown to the customer at submit time as provisional.

PayChoice Widget

Embed the hosted payment page.

Charging via the API

Create charges from your own systems.