Table of contents
Updated 1 September 2026. This guide keeps the original publication date and replaces its 2025 provider list with a current UK decision and integration guide.
A payment API connects your website, app or business system to a payment service. The right choice depends on the way customers pay, the checkout you want to build and the operational evidence your team needs after a payment starts.
Start with the customer journey. A small UK retailer adding Pay by Bank to an online checkout has different requirements from a subscription business collecting Direct Debit, a marketplace moving money between parties or an international merchant accepting many card and wallet methods.
This guide explains the roles, compares five current API routes and gives you an implementation checklist you can use with a developer or provider.
What a payment API does
An application programming interface lets two systems exchange requests and responses in a defined format. In a payment journey, your system might use an API to create a payment request, send the customer into a secure checkout, retrieve a status or reconcile the result against an order.
The API is one part of the service. The provider may also supply the hosted checkout, authentication journey, payment initiation, acquiring, collection, status events, settlement information and reporting. Our UK payment provider comparison explains those provider roles in more detail.
Payment API, gateway, processor and PISP
- Payment API: the technical interface your software calls.
- Payment gateway: a service that securely passes online payment information into the relevant payment flow. The term is most commonly associated with cards.
- Payment processor and acquirer: organisations that handle parts of card authorisation, clearing and settlement. A payment provider may combine several roles.
- Payment initiation service provider: a regulated provider that initiates an account-to-account payment after the customer gives consent through their bank.
- Hosted checkout: a provider-controlled page or component where the customer completes the payment journey.
- Webhook: a server-to-server notification sent when a payment or related resource changes state.
These labels describe different jobs. Ask each shortlisted provider which roles it performs, which parties handle the payment data and which event your system should use for fulfilment.
Payment APIs for UK businesses at a glance
| API route | Payment focus | Strongest fit | Implementation questions |
|---|---|---|---|
| Wonderful One API | UK Pay by Bank for websites, apps and business systems | UK businesses adding one-off bank payments to a checkout or workflow | Supported business bank, customer bank coverage, payment status, reference and reconciliation |
| Stripe PaymentIntents | Cards and a broad range of online payment methods | Digital businesses that need flexible checkout and payment-method coverage | Hosted or custom elements, PaymentIntent lifecycle, webhooks, idempotency and combined product costs |
| PayPal Orders API | PayPal checkout and eligible card-funded journeys | Businesses serving customers who want a PayPal checkout | Order creation and capture, approved versus completed status, webhooks and current merchant fees |
| GoCardless API | Direct Debit and recurring bank collection, with additional bank-payment products | Regular bills, memberships and subscription collections | Mandate lifecycle, collection timing, failed-payment handling, webhooks and payout reconciliation |
| Adyen APIs | Enterprise online, in-app and in-person payments across markets | Larger international or omnichannel merchants | Payment-method coverage, acquiring model, webhooks, idempotency, settlement reporting and commercial terms |
This is a fit comparison rather than a universal ranking. Provider products, availability and prices change. Check the current documentation and pricing for the payment methods, countries and account type you plan to use.
1. Wonderful One API for UK Pay by Bank
The Wonderful One API lets a UK business add Pay by Bank to a website, app or system. The business creates a payment request and the customer selects their bank, authenticates with that bank and authorises the payment. Wonderful publishes the API as language independent and links to developer documentation from its integrations page.1
The current Pro plan includes simple API access, multiple integrations and 2,400 monthly transactions for £96 plus VAT, with a 2p charge for each transaction above the allowance. Wonderful's pricing page routes API-first Open Banking integrations, higher volumes and custom terms to Asima.2
This route fits a business that wants to add one-off bank payments to its checkout while keeping a clear order reference and receiving payment status in its own system. Check your receiving bank, customer bank coverage and exact status handling before launch. The Pay by Bank payment stages guide follows the journey from request through authentication, authorisation, initiation, execution, funds availability and reconciliation.
2. Stripe PaymentIntents for broad online payment coverage
Stripe's PaymentIntents API tracks a payment through its lifecycle and supports payment methods that may require extra authentication. Stripe recommends creating one PaymentIntent for each order or customer session, reusing it if checkout resumes and using an idempotency key to avoid duplicate objects.3
Stripe also recommends server-side webhooks for payment success and failure. A browser returning to a confirmation page can be interrupted, so fulfilment should follow the relevant verified server event.4
Stripe suits a digital business that values flexible integration and broad payment-method coverage. The procurement work should include every Stripe product used, the card and customer mix, currency conversion, payment-method charges and the engineering effort needed to operate the integration.
3. PayPal Orders API for PayPal checkout
PayPal's Orders v2 API lets a server create, update, retrieve, authorise and capture an order. A typical flow creates an order on the server, sends the customer through PayPal checkout and captures the approved order from the server.5
PayPal exposes separate webhook events for states including approved, pending, completed, denied and reversed. Its guidance says a merchant should fulfil an order when the payment reaches the completed event appropriate to that integration.6
This route can serve customers who already use PayPal and businesses that want PayPal alongside other checkout methods. Confirm which funding methods your account can offer, the current UK fees and the event mapping used by your order-management system.
4. GoCardless API for recurring bank collection
GoCardless specialises in bank payments and is widely used for Direct Debit and recurring collection. Its API model includes customers, mandates, payments, events, webhooks and payouts. The choice fits regular bills, memberships and subscriptions where a mandate and collection schedule form part of the customer relationship.
The GoCardless go-live checklist asks implementers to simulate cancellations and failures, create live credentials, switch from sandbox endpoints, add a webhook listener and subscribe to API status updates.7 Its reconciliation guidance uses payout and payout-item records to connect collected payments, fees and adjustments to a payout.8
Model the mandate, notice, collection and payout stages explicitly. A submitted collection, a confirmed payment and a paid-out payment represent separate operating states.
5. Adyen APIs for enterprise and omnichannel payments
Adyen provides APIs for online, in-app and in-person payment journeys across many markets and methods. It is generally relevant to larger merchants that want acquiring, payment methods and operational reporting through an enterprise platform.
Adyen supports idempotency on POST requests. The same idempotency key can be used when retrying a request after a timeout, and Adyen recommends asynchronous server-to-server webhooks for payment results.9
Ask for a method-by-method commercial proposal and test the full path from payment request to settlement report. International coverage adds questions about entities, currencies, acquiring, local methods and reconciliation across markets.
How to choose a payment API
1. Map the payment job
Write down where the customer pays, the payment methods they need, the countries and currencies involved and whether payments are one-off or recurring. Include refunds only as an operational requirement to verify with the shortlisted provider. Do not assume that one API covers every payment route.
2. Choose the checkout model
A hosted checkout can reduce the amount of sensitive payment data handled by your systems. A custom checkout gives your team more control and usually adds engineering, security and maintenance work. For card payments, PCI Security Standards Council guidance says eligibility and scope depend on how payment-page elements are delivered and which systems receive cardholder data.10 Confirm your responsibilities with your acquirer, provider or qualified adviser.
3. Define each payment state
Create an internal status map before coding. Keep these events separate:
- The payment request or order is created.
- The customer authenticates with the relevant provider or bank.
- The customer authorises the payment.
- The provider accepts or initiates the instruction.
- The payment is processing, executed, failed or completed according to the provider's model.
- Funds are settled, paid out or available under the payment method and provider terms.
- The business reconciles the payment to the correct sale, invoice or account.
A successful API response may confirm that a request was accepted. It does not by itself confirm every later payment stage. Use the provider's documented status and webhook events for customer messages, fulfilment and finance records.
4. Compare full operating cost
Include subscription charges, transaction fees, percentage fees, overage, currency conversion, premium cards, optional products, hardware and developer time. Add the ongoing work needed for monitoring, provider changes, support and reconciliation. Use current official pricing rather than a rate copied from an older comparison.
5. Check data and security responsibilities
Record which personal and payment data your system collects, sends, stores and logs. The ICO says UK GDPR requires appropriate technical and organisational security measures. Its guidance also points businesses processing payment-card data to PCI DSS.11
Keep credentials in a secret store, restrict access, rotate keys when required and prevent sensitive values from entering application logs. Verify webhook signatures using the provider's current method. Collect the data needed for the payment and support journey, with retention tied to a documented purpose.
Payment API integration checklist
- Write the acceptance criteria. Define payment methods, countries, currencies, channels, volumes, status events, accessibility and support needs.
- Choose the hosted or custom journey. Document where payment data is entered and which party controls each page or component.
- Create a sandbox account. Test successful, abandoned, timed-out, failed and duplicate-request scenarios supplied by the provider.
- Assign one internal order reference. Pass a stable reference that can connect the checkout, provider record, bank receipt and accounting entry.
- Use idempotency where supported. Retrying a timed-out create or capture request should not create an unintended duplicate.
- Build a webhook endpoint. Verify signatures, acknowledge events promptly and process them safely if they arrive more than once or out of order.
- Map provider states. Decide which event updates the customer, releases goods, alerts support and posts a finance record.
- Protect credentials and logs. Separate test and live keys, restrict access and remove sensitive data from errors and monitoring.
- Test reconciliation. Match amount, reference, provider state, fee and settlement or payout record. The small-business payment reconciliation guide provides a practical control process.
- Plan for outages and changes. Define customer messages, manual checks, provider-status monitoring, version upgrades and an operational fallback.
- Complete a controlled launch. Use a small live test, verify the destination account and evidence, then monitor completion and failure rates against the provider's documented states.
Which route fits your business?
- UK Pay by Bank in your own checkout: review the Wonderful One API, supported banks and the current Pro plan. Larger API-first Open Banking requirements route to Asima through Wonderful's pricing page.
- Broad online card and payment-method coverage: compare Stripe's checkout options, PaymentIntent lifecycle, pricing and connected products.
- PayPal customer demand: compare the Orders API, eligible funding methods, webhook states and current UK merchant fees.
- Recurring bank collection: compare GoCardless mandate, collection, failure and payout workflows.
- International or omnichannel enterprise requirements: compare Adyen's methods, acquiring, integration, reporting and commercial proposal.
Your shortlist should make the complete customer and operational journey easier to run. Select the API that supports the required payment method, gives your systems reliable status evidence and produces records your finance and support teams can use.
Footnotes
- Wonderful: Wonderful One API, accessed 1 September 2026.
- Wonderful: plans and pricing, accessed 1 September 2026.
- Stripe: Payment Intents API, accessed 1 September 2026.
- Stripe: monitor a PaymentIntent with webhooks, accessed 1 September 2026.
- PayPal: use the Orders v2 API, accessed 1 September 2026.
- PayPal: payment-method webhook events, accessed 1 September 2026.
- GoCardless: go-live checklist, accessed 1 September 2026.
- GoCardless: reconciling payouts, accessed 1 September 2026.
- Adyen: API idempotency, accessed 1 September 2026.
- PCI Security Standards Council: payment pages and SAQ A eligibility, accessed 1 September 2026.
- Information Commissioner's Office: a guide to data security, accessed 1 September 2026.