The Revolut Business API gives businesses programmatic access to their Revolut Business account — initiating payments, retrieving transaction history, managing counterparties and receiving real-time event notifications via webhooks. For businesses that need to automate outgoing payments — paying customers for trade-ins, sending contractor payouts, triggering refunds — the Revolut API is one of the most practical solutions available. This guide covers how the API works, what safeguards a production integration must include, and what to expect from the build.
Finding good information about building payment automation on the Revolut Business API is harder than it should be. Most of what exists is basic documentation and shallow tutorials. This guide is written from the experience of building a production Revolut payout system for a high-volume UK trade-in business — the kind of system where getting it wrong means real money going to the wrong place.
What the Revolut Business API covers
The Revolut Business API is REST-based with OAuth 2.0 authentication. It covers:
Payments and transfers. Initiate payments to UK and international bank accounts, pay counterparties already saved in your Revolut account, transfer between your own Revolut accounts (multi-currency), and schedule future payments. This is the core capability for payout automation — your platform triggers a payment to a customer or supplier without anyone opening the Revolut dashboard.
Transaction history. Retrieve all transactions across your Revolut Business accounts, with filtering by date, amount, currency and transaction type. This powers reconciliation tools, financial dashboards and accounting sync.
Counterparty management. Create, update and retrieve counterparties — the bank account details of people or businesses you pay regularly. For trade-in platforms, each customer whose bank details have been verified becomes a counterparty that can be paid programmatically.
Account information. Retrieve balances across all your Revolut accounts, including multi-currency balances. Useful for treasury dashboards and cash flow monitoring tools.
Webhooks. Real-time notifications when payment states change — payment created, payment pending, payment completed, payment failed. Your integration receives these events and can act on them immediately: updating your platform’s order status, notifying the customer, triggering the next step in a workflow.
Authentication — how it works
The Revolut Business API uses OAuth 2.0 with a JWT (JSON Web Token) for the initial authorisation step. This is more complex than simple API key authentication but not as involved as Azure OAuth.
The flow: you generate an RSA key pair, upload the public key to your Revolut Business developer settings, and use the private key to sign a JWT when requesting an access token. The access token is then used as a Bearer token on all API requests. Access tokens expire and must be refreshed using a refresh token.
Both the private key and the refresh token must be stored securely server-side. Neither should appear in code repositories, client-side scripts, or unencrypted database fields. Key rotation is good practice and should be planned for as part of the integration design.
Revolut’s sandbox environment uses the same authentication flow as production, so all authentication logic can be tested fully before connecting to real funds.
Payment safeguards — non-negotiable
This is the section that distinguishes a production-ready Revolut payout integration from a demo or prototype. The API will fire payments when instructed. A poorly built integration can fire incorrect payments, duplicate payments, or payments to wrong accounts. The safeguards below are non-negotiable for any system handling real money.
OTP verification before payment release. Every payment above a configurable threshold requires a one-time password sent to the authorised approver’s mobile number via SMS (Twilio). The payment is created in a pending state, the OTP is sent, and the payment only proceeds when the correct code is entered within the expiry window. No OTP, no payment. This is the most important safeguard — it means a system compromise or a code bug cannot fire payments without a human in the loop.
Bank account name matching. Before creating a payment, the integration calls Revolut’s counterparty lookup to retrieve the registered account holder name for the destination sort code and account number. This is compared against the name provided by the customer. An exact match proceeds to the OTP stage. A close match (e.g. initials vs full name, maiden name) flags for manual review. A mismatch blocks the payment and alerts your team. This catches the most common fraud vector: customers providing someone else’s bank details.
Account number validation. Sort code and account number combination validated via modulus checking before any API call. Invalid combinations are rejected immediately with a clear error message. This prevents payments to account numbers that cannot receive funds — a more common input error than people expect.
Duplicate payment detection. The integration checks for an existing payment to the same account number for the same amount within a configurable time window before creating a new payment. Duplicates are flagged for manual review rather than processed automatically. This catches double-submission errors and protects against webhook retry events triggering duplicate payments.
Payment limits. Individual payment cap (e.g. no single payment above £500 without elevated approval), daily total cap (e.g. no more than £5,000 in automated payments per day), and weekly total cap. Payments that would breach a limit are queued for manual approval rather than rejected outright.
Velocity checks. Too many new counterparties added in a short window, or too many payments to new accounts, triggers a hold. This catches patterns that look like an account compromise rather than normal business operation.
Full audit log. Every payment attempt — whether it succeeded, was blocked by a safeguard, or failed at the API level — is logged with timestamp, destination account, amount, the safeguard check results, the OTP verification status and the API response. This log is the evidence trail for any payment query or dispute.
The counterparty workflow for trade-in platforms
For trade-in, buyback and similar platforms where the business pays customers, the typical flow is:
Customer submits their item for trade-in or buyback. Offer is accepted. Customer enters their bank details — account holder name, sort code, account number. The integration immediately runs the modulus check on the sort code and account number. If valid, it calls Revolut’s counterparty API to verify the account holder name. The name match result is returned. If the name matches within tolerance, the counterparty is created in Revolut and the record is stored against the customer order. If the name doesn’t match, the customer is asked to check their details before proceeding.
When the item is received and the payment is approved, the integration creates the payment in Revolut against the stored counterparty. The OTP is sent to the approving team member. On code entry, the payment is released. Revolut’s webhook fires when the payment completes, the integration updates the order to Paid, and the customer receives a confirmation.
For the full service and pricing, see the Revolut Business API integration service. For the automated payout system specifically, see automating payments with the Revolut API. For what the build costs, see the Revolut API integration cost guide.
Related posts
Testing in the Revolut sandbox
Revolut provides a full sandbox environment that mirrors the production API. Sandbox payments don’t move real money but behave identically to live payments in terms of API responses, webhook events and error handling. All development and testing happens in sandbox before connecting to a live Revolut Business account.
Testing should cover the full range of scenarios: successful payment with all safeguards passing, payment blocked by name mismatch, payment blocked by limit, duplicate detection triggering correctly, OTP expiry handling, failed payment webhook processing, and sandbox counterparty creation and retrieval. Thorough sandbox testing means the production go-live is low-risk.
Revolut’s sandbox also allows testing of the webhook flow — it fires webhook events for sandbox payments exactly as it would for live payments. This means the full end-to-end flow, from payment initiation through to webhook confirmation and order status update, can be tested before a single real payment is made.
Revolut vs Stripe or GoCardless for payouts
Revolut is specifically suited to businesses that already bank with Revolut Business and need to automate payments out of that account. It is not a general-purpose payment processor for taking card payments (that’s Stripe) or Direct Debit collection (that’s GoCardless). The decision is usually straightforward: if your business holds funds in Revolut Business and needs to pay out from that account programmatically, the Revolut API is the right choice. If you need to collect payments from customers, look at Stripe or GoCardless.
For trade-in and buyback businesses, Revolut is often chosen because the business already uses Revolut Business for its operational banking and wants payments to customers to come directly from that account with a familiar Revolut transfer reference for both parties. The alternative — using a dedicated payment processor for payouts — typically involves higher fees and more complex setup without meaningful benefits for straightforward UK bank transfers.
If you need help integrating the Revolut Business API into your platform or internal systems, I can help. I build custom payment and banking API integrations for UK businesses. See API integration pricing or get in touch.
Need a custom integration built?
I build custom API integrations — Stripe, Companies House and bespoke data pipelines. Reliable, well-documented, no agency overhead.
Discuss your project →