If you run a trade-in website, a mobile phone buyback platform, a laptop recycling service, a gold buyer, a car part-exchange site, or any business that pays customers money in exchange for something they’ve sent you — automated payments via the Revolut Business API is one of the best solutions available and one of the hardest to find good information about.
The challenge: you need to pay customers quickly, accurately and safely, at volume, without anyone manually logging into a banking portal for every payment. The risk: unlike sending a parcel to the wrong address, sending money to the wrong bank account is a genuinely serious problem. The solution: a properly built Revolut API integration with the right safeguards built in from the start.
This post covers the complete payment automation flow for trade-in and buyback sites — from customer bank detail capture through to the payment arriving in their account — along with every safeguard that makes it safe to run at scale.
The problem automated payments solves
Without automation, the payment flow for a trade-in business looks like this: item arrives, it’s graded, the offer is confirmed, someone logs into Revolut Business, finds the customer’s bank details from the order management system, manually enters the sort code and account number, types the amount, checks the reference, and sends the payment. Multiply this by 50, 100, 200 payments per day and it becomes a significant daily overhead — and manual bank transfers are where mistakes happen.
A wrong digit in the account number. Correct details but wrong customer’s order. Right order but wrong amount because someone misread the grade. Right payment but no reference, so the customer can’t identify it. These aren’t hypothetical errors — they happen in any manual payment process at volume.
Automation removes every manual step. The order management system triggers the payment when the item is graded and accepted. Bank details are validated automatically. The payment amount comes from the order record — no manual input. The reference is generated automatically from the order number. A human only touches it to enter an OTP — and even that can be configured to run automatically for payments below a certain threshold once you’re confident in the system.
Who this applies to
Mobile phone buyback sites. The original use case. High volume, relatively low average payment values, customers expecting fast payment after sending their phone. Manual payment processing at 100+ phones per day is genuinely unmanageable. Automation makes same-day payment a realistic offer rather than an aspiration.
Laptop and electronics recycling. Similar pattern to mobile buyback but higher average values. The name matching safeguard is particularly important at higher values — a £400 payment to the wrong person is a more serious problem than a £20 one.
Gold, jewellery and precious metal buyers. Customers post items, items are assessed, payment is made. High value, relatively low volume. The safeguards need to be robust because individual payment values are significant. OTP on every payment regardless of threshold makes sense here.
Car part-exchange platforms. Online car buying platforms where customers get an instant quote and post or drop off the vehicle. Payment automation for the settlement amount, with the checks and limits appropriate for payments in the thousands rather than hundreds.
Book, game and media buyback sites. Lower value but very high volume. Automation is essential for profitability at scale. Strong duplicate detection is important because these platforms often see customers submitting multiple items in a short period.
Freelancer and contractor payout platforms. Agencies, staffing platforms and gig economy businesses paying weekly or monthly to large numbers of contractors. Different use case to trade-in but the same automation pattern — payroll data drives the payment amounts, Revolut API fires the transfers.
The complete payment flow
Step 1: Bank detail capture. The customer enters their sort code and account number in your platform. Before anything else happens, the integration runs a modulus check — a mathematical validation that confirms the sort code and account number combination is valid. Invalid combinations are rejected immediately with a clear error message. This catches typos and invalid account numbers before they cause problems later.
Step 2: Name verification. The integration calls Revolut’s counterparty API to look up the registered account holder name for the sort code and account number. This is compared against the customer’s name on the order. An exact or close match (handling common variations — initials, hyphenated surnames, Ltd/Limited) proceeds. A mismatch flags the order for manual review with the mismatch details shown to your team. This check happens at bank detail entry time, not at payment time — so mismatches are caught early and don’t hold up the payment queue.
Step 3: Counterparty creation. If the name check passes, a counterparty is created in your Revolut Business account using the customer’s bank details. The counterparty ID is stored against the customer record in your system. Future payments to the same customer use the stored counterparty — the bank details don’t need to be re-entered or re-verified unless they change.
Step 4: Payment trigger. When the item is graded, accepted and the payment is approved in your order management system, the integration creates the payment in Revolut against the stored counterparty. The payment is created in a pending state — it hasn’t been sent yet. At this point, limit checks run: is this payment within the per-payment cap? Does it push the daily total over the daily limit? If checks pass, the OTP step fires.
Step 5: OTP verification. An SMS is sent via Twilio to the authorised approver’s mobile number with a 6-digit code. The approver enters the code in the platform. On successful verification, the payment is released. The code expires after 10 minutes. After 5 failed attempts, the payment is locked and requires manual intervention. No OTP, no payment — regardless of what else the system says.
Step 6: Payment confirmation. Revolut’s webhook fires when the payment status changes to completed. The integration receives this event, updates the order status to Paid, and triggers the customer confirmation — an email or SMS telling the customer their payment is on its way. The full audit trail — name check result, OTP verification, payment creation, webhook confirmation — is logged against the order.
Handling edge cases and failures
Name mismatch. The customer says their name is “John Smith” but the account is registered to “Jonathan Smith” or “J Smith”. The integration flags this for manual review with the mismatch shown clearly. A team member can approve manually if they’re satisfied it’s the same person, or contact the customer to provide matching details.
Payment fails after release. Occasionally a payment fails after the OTP is entered and the payment is released — the account is closed, frozen, or the bank rejects the transfer. Revolut’s webhook fires a failure event. The integration catches this, marks the order as payment failed, alerts your team, and holds the funds in Revolut. No automatic retry — a failed payment to an unverified account should always go to manual review before attempting again.
Customer changes bank details. If a customer updates their bank details after the counterparty is created, the old counterparty is archived and the new details go through the full verification flow again. There is no shortcut around the name check for updated details.
Duplicate detection. The same customer submits the same bank details twice in quick succession, or a webhook retry causes the payment creation call to fire twice. The integration stores a unique payment reference per order and checks for it before creating a new payment. A payment that already exists for this order reference is not created again — it returns the existing payment status instead.
For the full service details, see the Revolut Business API integration service. For the complete API guide, see Revolut Business API integration guide. For what the build costs, see the Revolut API integration cost guide.
Related posts
If you need help with a custom API integration for your website or business application, I can help. I build bespoke API integrations for UK businesses. See API integration pricing or get in touch to discuss your project.
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 →