Evaluate the integration before you commit.
Your developers connect the payment products to your software. We work out what needs building with you and answer the payments questions while you build. Start with the documentation, then talk to us about test access and your plan.
Work out how the payments will run
First, agree how payments will work for your software platform or marketplace: which accounts you need, how customers pay and what records your software needs back. Software-platform merchants are settled in full. Marketplace payments use their own split-at-capture model.
Then work out what your software needs to do: where customers start, how the server connects, how you handle events and how you keep your records up to date. See who builds what before estimating your integration.
Get the correct test access
The public quickstart describes account setup and the first request. The environments guide provides separate test and production endpoints and dashboards. Test credentials are tied to the test environment; they do not provide production access.
Test access is arranged with our team: tell us what you are building and a payments engineer sets it up with you. A test account does not establish a live commercial or acquiring arrangement.
Keep secret API credentials on your server. Use the documented client-side key for browser integrations. Follow the authentication guide for the account and key requirements.
Work through the integration
Five steps, in order. The time they take depends on what you are building, the account requirements and your developers. We work through the steps with you before you promise a date to customers.
Step 1 of 5
Check access
Retrieve your account in the test environment using the first request in the documentation.
Check what works before going live
On a narrow screen, scroll within the table to read every column.
| Check | Evidence to review |
|---|---|
| Environment separation | The software uses the correct endpoints and credentials, without putting secrets into browser code or support messages. |
| Payment and customer records | The payment reference connects to the intended local customer or invoice and the result is visible in the right workflow. |
| Webhooks | The receiver verifies signatures and handles repeated or unsuccessful deliveries without duplicating business actions. |
| Failure and recovery | Your team can distinguish an unsuccessful payment from an integration error and knows the next action for each. |
| Reconciliation | The finance workflow follows the appropriate gross-settlement or marketplace model, including agreed refund and dispute handling. |
| Operations | Contacts, escalation and responsibility for product and provider issues are documented. |
Documentation for your review
- Quickstart: prerequisites and first request
- Authentication: server and client credentials
- Environments: test and production configuration
- Webhooks: event types, signature verification and delivery
- API reference: resources and supported operations
Use the documentation to check how the interfaces work. We confirm which capabilities you need and how the accounts should be set up for your integration.
Agree what needs to happen before going live
Before live processing starts, work through the technical, commercial and onboarding requirements with the people responsible. Check the test results, any problems still open, who will handle support and how the live account will be set up.
We send the next steps in writing. Read who handles what and how the commercials work alongside the technical plan.
More detail for your team
Share the detail with the people who will build, price and run payments with you.
- What we build together
- Commercial model
- Operations and responsibilities
- Technical evaluation (this page)
Start with a payments review
Tell us what you are building and what your developers need to check. We help work out the next steps and the right test access.