Architecture & API
Written by
Last editedMay 20261 min read
If you are integrating a payments provider, the quality of the technical architecture matters as much as the commercial terms. This section covers API design, webhook reliability, documentation quality, authentication, system integrations, and the developer experience in test environments.
Suggested questions to ask your potential provider include:
| # | Question | Explanation |
|---|---|---|
| 1 | What direct debit and bank debit schemes do you support (e.g., Bacs, SEPA, BECS, Autogiro, PAD)? | Understand which schemes are natively supported versus handled via a partner. Native support typically means better failure-code granularity, faster settlement, and tighter scheme compliance. |
| 2 | How do we interact with the direct debit scheme? Do you provide dedicated Service User Numbers (SUNs) or operate under your own SUN via managed administration? | The choice affects brand control, cash flow, and regulatory responsibility. You may have regulatory requirements about how funds flow between accounts. |
| 3 | Does your system support variable direct debits, allowing payment amounts to change between collections? | Variable debits are essential for usage-based billing, invoice collection, and any model where the amount collected differs each cycle. Not all providers support this cleanly. |
| 4 | How are failure and return codes presented, and with what level of detail? | Granular failure codes (e.g., distinguishing ‘insufficient funds’ from ‘account closed’) allow you to route failures intelligently, meaning retrying some, cancelling others, or prompting customers to update details. Providers that only surface generic failure codes limit your ability to act. |
| 5 | Can your solution enable Open Banking connections for single, instant account-to-account payments? | Pay by Bank (Open Banking-powered instant payments) is increasingly used alongside or instead of card payments for one-off invoices, checkout flows, and high-value transactions. Understand whether this is a native capability or a third-party wrap. |
| 6 | Does your platform support recurring Pay-by-Bank payments (also called VRPs)? | VRPs allow recurring payments to be initiated in real time with per-payment customer authorisation already in place. Ask whether VRP support covers commercial use cases, not just ‘me-to-me’ sweeping. |
| 7 | How do you optimise the payer experience for Open Banking payments, and how does your solution reduce drop-off during bank authorisation? | Open Banking conversion is heavily influenced by the quality of the bank-selection and authorisation flow. Ask about bank coverage, retry logic, and what happens when a payer’s bank is unavailable. |
| 8 | What is your payment success rate for Open Banking payments after payer authentication is initiated? | Success rate post-authentication is the key metric. It tells you how effectively the provider handles bank-side errors, timeouts, and edge cases that occur after the payer has already tried to pay. |
| 9 | What options do you provide for initiating both one-off and recurring payments? For example via API, dashboard, bulk file upload, and payment links? | Flexibility in initiation methods matters for different team workflows. Finance teams may use dashboard or bulk upload; developers prefer API; sales teams may send payment links. Ensure all the channels you need are genuinely production-ready. |
| 10 | Do you support payment initiation via multiple channels such as website, email, SMS, mobile app, and QR code? | Multi-channel payment collection improves conversion by meeting payers where they are. QR codes and SMS links are increasingly important for in-person and paper-based billing contexts. |
| 11 | Can your platform support payment schedules configured in advance, such as bi-monthly, quarterly, or custom-interval billing? | If your billing model includes irregular schedules, verify this is supported natively. Workarounds (e.g., creating individual payments manually) do not scale. |
| 12 | How does your solution handle the end-to-end lifecycle of a mandate, including creation, amendment, cancellation, and re-instatement? | Mandate lifecycle management determines how much operational overhead falls on your team. Providers who automate notifications, handle bank amendments, and support reinstatement of lapsed mandates reduce manual work significantly. |
| 13 | How does your platform verify that a customer’s bank account details are accurate before a mandate is submitted? | Bank account verification (e.g., via Confirmation of Payee or Open Banking account checks) prevents failed mandates, reduces fraud, and eliminates wasted collection attempts against invalid accounts. |
| 14 | Do you provide a complete audit trail for mandate events, including customer consent records? | A mandate audit trail is essential for dispute resolution and regulatory compliance. You should be able to demonstrate when and how a customer authorised a mandate, and what notifications they received. |
| 15 | Does your solution offer flexible payment date collection, giving merchants control over when payments are collected relative to scheme submission windows? | Scheme rules impose minimum notice periods and submission windows. Understanding how much flexibility you have to control collection dates, and how the provider manages this, affects your ability to align collections with customer pay cycles. |
| 16 | Do you provide automated retry logic and recovery workflows for failed or abandoned payments? | Automated retries for failed payments is one of the most commercially significant features to evaluate. Manual retry processes do not scale. |
| 17 | What percentage of failed payments does your recovery tooling successfully recollect, and over what timeframe? | Ask for data specific to businesses similar to yours. A recovery rate of 60-70% of failed payments represents significant recovered revenue. |
| 18 | Upon collection, are funds transferred directly into our bank account, or do they pass through your account first? | This is the facilities management vs. managed administration distinction. Direct-to-merchant settlement gives you faster access to funds but limits the additional services a provider can support you with. |
| 19 | What are your standard payout timings by payment scheme, and do you offer faster or configurable settlement options? | Settlement timing directly affects working capital. Some providers offer daily payouts; others batch weekly. Understand the timeline from collection date to funds in your account for each scheme you use. |
| 20 | Does your platform support outbound payments, beyond just refunding existing payments? Ie. the ability to send funds directly to customers or third parties? | Outbound payments (e.g., newly created payments from you to a recipient such as supplier payments, or customer payouts) are increasingly relevant as payment providers expand beyond collection. Understand whether this is a native feature or requires a separate product. |
| 21 | How does your solution manage both partial and full refunds, including the timing and method of refund processing? | Understand whether refunds are processed via the original payment scheme or via an alternative route (e.g., bank transfer). Timing, costs, and customer communication differ materially between approaches. |
| 22 | Can your platform verify the recipient of a refund using Confirmation of Payee or equivalent, to ensure funds reach the correct account? | Refund fraud and misdirected funds are genuine risks, particularly for high-volume merchants. Account name verification before sending refunds is best practice. |
| 23 | How does your solution manage indemnity claims and chargebacks, including evidence submission and lifecycle tracking? | For direct debit, payers have an unconditional right to reclaim. Understand how the provider tracks claims, supports your evidence submission, and protects you against fraudulent claims. |
| 24 | What specific fraud detection controls and duplicate payment prevention mechanisms does your platform provide? | Ask for specifics: what signals are used, what thresholds trigger review, and how duplicate detection works. Generic answers (‘we take fraud seriously’) are not sufficient. |
| 25 | What continuous improvement programmes do you have in place to optimise payment success rates, conversion, and payer experience? | A provider committed to improving outcomes should be able to point to specific programmes: A/B testing of payment flows, scheme engagement to reduce failures, or machine-learning models for recovery timing. |
| 26 | What does your product roadmap look like for the next 12–24 months, particularly for new payment methods and regulatory changes? | The payments landscape is changing fast. A provider’s roadmap tells you whether they are keeping pace and whether their direction aligns with yours. Selecting a forward-thinking provider minimises the chance of having to move to another solution in coming years. |
Sample RFP
Our sample RFP includes all of the questions in this guide and more. You can download it and use it as a template for creating your own.
Note: The questions suggested on this page are intended as a starting place for writing your own RFP. They're provided for general information only: they're not intended to be prescriptive or to provide legal advice. We suggest working closely with your management to develop an RFP that is tailored towards the specific requirements of your business.
