Build with Access PaySuite

Cards, digital wallets, Direct Debit and pay by bank, documented in one place.

Access PaySuite gives you the UK payment methods your customers actually use. Cards and digital wallets for one-off, recurring and instalment sales or payments to customers. Direct Debit for the recurring relationship using bank transactions. Pay by bank for the instant, low-cost alternative.

We have been running regulated payments infrastructure for a long time, for organisations that range from sole traders through to national charities and household-name energy suppliers. That experience shows up in the parts of an integration that usually hurt: detailed field-level schemas, worked examples you can paste straight into a terminal, and error tables that tell you what to do next rather than just what went wrong.

Read this before you start

Cards and wallets and pay by bank are part of the Advanced Payments family, and they share the base URLs and credentials with some small differences in the payment flow. Direct Debit is separate, with its own base URLs and credentials. They are documented together, but they are not one API behind one key. If you are integrating more than one payment method, treat each as a separate piece of work.

Both API families support a wide range of organisation structures, from simple to more complex ones, let us know about your requirements and we'll guide you on the appropriate organisation setup. The test accounts start with a simpler setup and they can be updated as needed.

Whichever you are building against, never call these APIs from a browser or a mobile app. Every request carries your credentials, so they belong on your server only.

Worth knowing about the Advanced Payments APIs: they return 200 on success, or 201 where your call created a new resource, and all requests must use TLS v1.2 or higher. We will not remove a response field without advance notice, but we may add new ones at any time, so build to tolerate fields you have not seen before.

Quickstart your integration puts each product's quickstart and overview side by side, whether you are building against one of them or all three.

Cards and digital wallets

Card payments, payouts, saved payment methods, recurring and instalment payments, Apple Pay, Google Pay and PayPal. Mobile SDK available.

• Using the APIs covers credentials, Basic authentication, the test and live base URLs, and the anatomy of a request.
• Integration Options helps you choose between the PaySuite payment page, your own payment page and the mobile SDK.
• Cards and Wallets API Endpoints is the full endpoint and schema reference.
• Test Cards for a list of test cards you can use for different scenarios.
• Response Codes and Messages is the reference for handling failure properly.

Direct Debit

Create customers, build contracts, take one-off and scheduled payments, amend and cancel mandates, and receive Bacs reporting back into your own systems.

• Customer Manipulation is the best example of how we document a Direct Debit resource. Field-by-field definitions with lengths and formats on the left, worked request and response examples on the right, and an error table at the foot of the page. Start here to get a feel for the shape of the API.
• Return Payloads is the reference for everything we send back to you, including the Bacs return reports. Read it alongside Return Endpoints when you set up your callbacks.
• Direct Debit API Endpoints is the complete endpoint and schema reference.
• The Direct Debit Process and Working Days are short reads that will save you a lot of debugging. Bacs runs on a working-day cycle and your integration has to respect it.
• Errors and Environments cover failure handling and base URLs.
• Using the API and UI together is the one to read if your operations team will be working in the Direct Debit interface alongside your integration.

Three things that catch people out:

You must modulus check bank account numbers and sort codes before sending them to us. That is your responsibility, not ours. Failing to do it is likely to cause problems processing your payments. We can provide a bank checking API on a pay-per-use basis if you need one.

Bank details need cleaning first. Account numbers are eight digits with leading zeros intact, sort codes are six digits with any hyphens stripped, and the account holder name is a maximum of eighteen alphanumeric characters with punctuation removed. Validate at your end rather than discovering it in a 400.

A Direct Debit is a schedule, not a transaction. A card payment either works or it does not, and you know within seconds. A Direct Debit is a multi-day Bacs cycle with return reports arriving after the collection date. Model that from the outset rather than retrofitting it.

Pay by bank

One-off payments where the customer authenticates with their bank to approve the payment.

• Quickstart and Overview explain the model and where it fits alongside the cards and wallets payment methods.
• PaySuite Payment Page and Your Payment Page cover the two integration routes.
• Pay by Bank API Endpoints is the endpoint reference, and Testing covers how to prove it without real money.

Where to go for what

Need a hand?

Our Implementations team issues your live credentials once your integration is complete and your account is ready. If you get stuck before then, tell us which endpoint and environment you were calling. It is the fastest way to get you moving again.

Contact us — sales for a sandbox account or a new integration, technical support for a specific technical question.