Developers
A documented REST API, and a payments engineer while you build.
A REST API and webhooks that do what the docs say, test accounts to build against, and a payments engineer who answers the payments questions rather than handing you a PDF.
Work out what needs building first.
We work through the payment flows, customer experience and who handles what with your product and commercial teams. Your developers then connect your software to our API and SDK, with a payments engineer here to answer the payments questions.
What you build against
A predictable REST API
Take payments, collect by Direct Debit and reconcile, over a REST API that behaves the way the reference says it does.
API reference →Events you can build on
Payments, collections and settlement fire webhooks your system can act on, so your flow reacts to money moving in real time.
Webhook guide →Test before you sign
Run test payments and collections against real behaviour before a single live transaction moves. Nothing is charged and nothing is signed.
Talk to a payments engineer →Not on your own
Payment products and your integration
You get in writing which payment products we build and what your developers connect to your software. Those decisions sit alongside what customers get, what they pay and how you will introduce the offer.
While you build, our payments engineer answers payments questions and helps investigate problems with our systems or the underlying payment infrastructure.
- What we build, in writing
- Your developers connect your software
- Documentation and a test environment
- A payments engineer to ask
Documentation, testing and reliability
A test environment, not a demo
A separate base URL, its own dashboard and its own keys, so nothing you build against it can touch real money. Keys are environment-bound and will not work in the other one.
Read the environments guide →Idempotency, so a retry is safe
Every mutating request takes an idempotency key, so a timeout your end cannot become a double charge on your customer's card. This is the part that decides whether a payments API is safe to build on.
Read the idempotency guide →Before you recommend us
What your developers will want to check, and what to send the rest of the team.
- Your developers: Technical evaluation
- Scope: What we build and what you connect
- After launch: Who handles support and incidents
Start with the docs, or start with a person
Read the documentation at your own pace, or tell us what you're building and a payments engineer will answer your questions.