API-driven onboarding

The REST API accepts structured merchant application data covering the legal entity, ownership, trading activity, settlement details and requested payment capabilities. Payload requirements can vary by business model, jurisdiction and acquirer partner, with nested objects used for related parties and operating information.

Responses identify accepted data and any fields requiring correction, allowing platforms to map validation outcomes directly into their application workflow before provisioning continues.

The payload generally includes the legal entity name, trading name, registered address, and company registration number. Additionally, it must contain details for all individuals with a 25% or greater ownership stake, including their full name, date of birth, and home address.

Financial data such as expected annual volume, average transaction value, and the nature of the business (MCC) are also required. Bank account details for settlement, often verified through an IBAN or bank letter, must be provided to complete the setup.

Yes, payment orchestration platforms typically use a unified API that abstracts the specific requirements of different acquirers. This allows a platform to submit one set of merchant data which is then translated into the specific formats required by various global or local banks.

This is particularly useful for cross-border operations where different regions have distinct document formats and regulatory requirements. The API manages the routing and status updates for each individual connection.

Data security is maintained through encrypted HTTPS connections and, often, dedicated document upload endpoints that specialise in handling sensitive PII. Documents are typically tokenised or hashed, and access is restricted according to the principle of least privilege.

Under PCI DSS and GDPR, the platform must ensure that any stored data is encrypted both at rest and in transit. Using an API allows for direct, secure hand-offs to the acquirer's secure vault, minimising the platform's exposure to sensitive data.

In the payments industry, manual review remains a standard practice for high-risk MCCs, businesses with non-standard ownership structures, or those with high predicted processing volumes.

The API-driven approach does not eliminate manual review but rather optimises the process by providing the underwriter with a structured, digital file rather than a disparate collection of documents.

This allows the human reviewer to focus solely on the risk decision rather than data collection or administrative verification.

If an application is declined, the API will return a specific refusal code and, in some cases, a reason for the decline. Common reasons include failed KYB checks, credit history issues, or being in a restricted business category.

The platform can use this information to inform the merchant or to trigger a dunning-like process where the merchant is asked to provide alternative documentation or update their business information to address the specific concerns raised by the acquirer.