Meet us at conferences around the world
SiGMA Europe
An acquirer in a box is a packaged technology stack that helps banks, payment institutions and PSPs launch or expand merchant acquiring services without developing every component in-house. Depending on the provider, it may include payment acceptance, merchant onboarding workflows, transaction routing, risk management, reporting and reconciliation.
An acquirer in a box gives a licensed bank, neobank or payment institution a ready acquiring technology stack, so it can serve merchants without building the gateway, routing and merchant tooling itself. With Payneteasy, that stack is a payment technology and control layer: you keep your licence, your acquirers and your own risk.
But acquiring technology is only part of the business. A ready-made platform does not automatically provide regulatory authorisation, card scheme membership or the right to onboard and settle merchants. Those responsibilities depend on the institution’s licensing arrangements, acquiring relationships and operating model.
This guide explains what an acquirer-in-a-box solution typically includes, which responsibilities remain outside the technology stack, and what financial institutions should verify before choosing a provider.
Acquirer in a box is an industry term for a packaged acquiring technology solution. Rather than building separate systems for payment acceptance, merchant management, risk controls and transaction reporting, a financial institution can deploy an existing platform and configure it around its business requirements.
The term does not describe a single regulated product or standardised service. Different providers use it to describe different operating models.
Three common approaches are:
These models should not be treated as interchangeable.
For example, a licensed bank modernising its merchant acquiring operations may need only the technology layer. A fintech company without acquiring permissions may need a sponsoring institution before it can offer merchant acceptance under its proposed business model.
The first question is therefore not simply what software is included. It is who is legally and contractually responsible for each part of the acquiring service.
A complete merchant acquiring operation requires several interconnected capabilities. Some can be supplied as software, while others depend on regulated institutions, card networks and external service providers.
| Component | What the technology can provide | Who retains responsibility |
|---|---|---|
| Payment acceptance | Payment gateway, APIs, checkout and authentication integrations | The contracting payment service provider or acquirer |
| Merchant onboarding | Merchant profiles, document collection and workflow management | The institution responsible for merchant due diligence and acceptance |
| Transaction routing | Connections to processors, routing rules and eligible fallback routes | The institution defines its commercial and risk policies |
| Fraud management | Transaction screening, configurable limits and monitoring | The responsible acquirer or payment institution sets and enforces its risk policy |
| Merchant management | Merchant settings, permissions and operational dashboards | The institution operating the merchant relationship |
| Reporting and reconciliation | Transaction records, settlement data reconciliation and financial reports | The institution and its financial partners verify and resolve discrepancies |
| Dispute management | Chargeback notifications, case tracking and supporting data | Liability and decision-making follow scheme rules and contractual agreements |
| Clearing and settlement | Interfaces, files and reporting that support settlement operations | Authorised acquiring, processing and settlement participants |
Not every acquirer-in-a-box provider supplies every component. A platform may offer extensive gateway and orchestration capabilities without directly processing scheme clearing files or moving settlement funds.
This distinction should be explicit in the product specification and commercial agreement.
Merchant-facing payment technology is often the starting point.
It provides the connection between a merchant's checkout and the payment infrastructure used to process a transaction.
Typical components include:
These capabilities reduce the need to develop and maintain separate payment integrations for every merchant-facing application.
However, a gateway that transmits an authorisation request is not necessarily the institution that authorises the payment. The card issuer makes the approval or decline decision through the applicable card-network and processing infrastructure.
An acquiring operation needs to collect merchant information, maintain account records and apply eligibility requirements.
Technology can support document collection, merchant profiles, permissions, onboarding workflows and integration with external verification services.
It does not automatically assume responsibility for KYB checks, merchant underwriting or final acceptance decisions.
Those responsibilities depend on the regulated acquiring arrangement. Even when onboarding is highly automated, the institution responsible under the applicable rules must retain appropriate oversight.
Acquiring institutions need visibility into the risks associated with their merchant portfolios.
A technology stack may provide transaction velocity controls, configurable fraud filters, monitoring of unusual activity, limits and alerts.
The operational distinction is between providing risk-management tools and owning merchant risk.
The platform can help implement controls, but the responsible financial institution or sponsor determines its risk appetite, merchant acceptance criteria and responses to suspicious activity.
Institutions working with multiple acquiring or processing partners need a way to manage payment flows and compare operational results.
A routing layer can select an available provider based on transaction attributes, configured rules and commercial conditions.
Where supported, cascading can retry eligible unsuccessful transactions through an alternative provider, subject to decline codes, scheme restrictions and risk policies.
Reporting tools can then consolidate transaction records, processing fees, provider statements and settlement-related information.
However, reconciliation software does not itself settle funds. It helps institutions identify what has been authorised, captured, reported or settled and investigate differences between those records.
These two terms overlap, but they describe different levels of a payment business.
A white-label payment gateway primarily provides the technology for branded payment acceptance. A company can offer merchants payment pages, APIs, transaction management and related services under its own name.
An acquirer-in-a-box solution is generally positioned around a broader acquiring operation, potentially extending to merchant onboarding, portfolio management, risk oversight, disputes and settlement-related workflows.
| Capability | White-label payment gateway | Acquirer-in-a-box offering |
|---|---|---|
| Branded payment acceptance | Core capability | Common component |
| Merchant management | Often included | Usually important |
| Multi-acquirer routing | Depends on the platform | Depends on the platform |
| Underwriting workflows | Optional | Often expected |
| Dispute management | Optional | Often expected |
| Scheme processing and settlement | Generally outside gateway scope | Must be verified separately |
| Licence or sponsorship | Not inherently included | May be arranged separately |
The comparison is not a rigid product classification. An advanced white-label gateway with orchestration, merchant management and reconciliation may provide much of the technology required in an acquirer-in-a-box model.
What matters is whether the platform covers the institution's actual operational requirements.
For organisations comparing ready-made payment infrastructure, our guide to choosing a white-label payment gateway provider explains the broader vendor selection criteria.
Deploying acquiring software does not establish the legal right to provide acquiring services.
Before launching, an institution must determine which regulatory permissions, card-network arrangements and contractual relationships its business model requires.
These requirements vary by jurisdiction and operating structure.
For example, the European Banking Authority identifies acquiring of payment transactions as a regulated payment service under PSD2. Providing that service in the EU requires the relevant authorisation.
An acquiring operation must also address several responsibilities that technology alone cannot replace.
A business may provide acquiring services under its own relevant permissions or participate through an authorised partner, where that structure is permitted.
Card scheme participation, acquiring sponsorship and processing connections are separate considerations. Having access to a payment gateway does not establish any of these arrangements.
The institution responsible for acquiring must ensure that merchant acceptance, due diligence and ongoing monitoring meet the applicable requirements.
Technology can organise information and support risk decisions, but it does not transfer the institution's regulatory or contractual obligations to the software provider.
The movement of merchant funds follows the agreed acquiring, processing and settlement structure.
A payment technology provider may generate reports and support operational reconciliation without holding merchant funds or assuming settlement obligations.
Prospective buyers should establish which entity receives settlement funds, which entity owes payment to the merchant, and who is responsible for reserves, delayed settlement and financial losses.
Using an assessed payment technology platform may help reduce the scope of an institution's cardholder data environment, depending on the integration architecture.
It does not automatically eliminate the institution's PCI DSS obligations.
The institution should confirm the provider's current compliance evidence, the services covered by its assessment, and the PCI DSS responsibilities retained by each party.
The PCI Security Standards Council provides guidance on managing these responsibilities when third-party service providers are involved.
For a broader explanation of permissions, infrastructure and payment business models, see how to start a payment processing company.
Consider a bank that already has the necessary acquiring arrangements and wants to offer online payment acceptance to its business customers.
Instead of developing an entire merchant payment platform internally, it integrates a third-party technology stack into its existing acquiring operation.
A typical payment flow looks like this:
The bank completes the required merchant checks, makes the acceptance decision and establishes the relevant contractual relationship. The technology platform supports the merchant's operational configuration.
A customer enters payment details through a hosted payment page, secure embedded fields or another supported checkout integration.
The gateway securely processes the payment request according to its configured integration method.
Routing rules determine the acquiring or processing connection used for the transaction, based on the institution's configuration and available processing arrangements.
The request travels through the relevant acquirer, processor and card network to the issuer, which returns an authorisation response.
The platform records the result and provides the appropriate response to the merchant's payment application.
Captured transactions proceed through the applicable clearing and settlement arrangements. The technology platform can provide transaction records and reconciliation information for the bank's finance and operations teams.
In this model, the bank retains its acquiring role while the technology provider supplies the software needed to operate and manage the payment flows.
The arrangement can reduce the amount of infrastructure the bank has to build internally without changing its underlying regulatory responsibilities.
An effective vendor assessment should cover more than the number of available integrations or the speed of initial deployment.
The following questions help establish whether a proposed platform fits the institution's actual acquiring model.
Request a clear breakdown of payment acceptance, transaction processing interfaces, onboarding, routing, fraud controls, reconciliation and dispute management.
Confirm which capabilities are included, optional or delivered by third parties.
Establish whether the proposed solution is technology-only or depends on a licensed acquiring or sponsoring partner.
Ask who contracts with merchants, who controls underwriting and who carries the corresponding obligations.
Identify every party involved in clearing and settlement, including the legal responsibility for paying merchants.
Ask whether the technology provider handles settlement reporting only or supplies other services through an authorised arrangement.
Check the supported integrations, geographical coverage, payment methods and any certification requirements.
Where new connections are needed, obtain a realistic implementation plan and clarify who is responsible for maintaining them.
Request relevant PCI DSS compliance documentation, information about supported integration models, and a clear responsibility matrix.
Confirm where cardholder data is processed and which systems remain within your organisation's assessment scope.
Ask for a project-specific plan covering configuration, integrations, acceptance testing, security checks, operating procedures and external approvals.
A rapid gateway deployment should not be confused with the time required to establish a complete acquiring operation.
The most useful outcome of this review is a written responsibility matrix. It should distinguish the technology vendor's obligations from those of the bank, sponsoring acquirer, processing partners and other service providers.
An acquirer-in-a-box platform can make merchant acquiring technology more accessible to banks and payment institutions. It can replace multiple internal software projects with an integrated set of payment acceptance, routing, risk and operational tools.
But the value of the solution depends on how clearly the technology responsibilities are separated from regulated acquiring activities.
Before selecting a provider, establish who owns the merchant relationship, which institution is responsible for settlement, what the platform actually processes and which obligations remain with your organisation.
If your institution already has acquiring or sponsoring arrangements and needs a payment gateway, orchestration or merchant management technology, Payneteasy can help you build the technology layer around that operating model.
Contact the Payneteasy team to discuss your acquiring infrastructure and integration requirements.
Not necessarily. Some offerings provide only acquiring technology, while others involve an authorised sponsoring or acquiring partner. Software alone does not grant regulatory authorisation or card scheme membership. The required arrangements depend on the jurisdiction and business model.
Yes, provided its intended acquiring activities are supported by the necessary permissions or an appropriate authorised partner arrangement. Being a neobank or payment institution does not automatically mean the company is authorised to provide merchant acquiring services.
No. A white-label gateway mainly provides branded payment acceptance and related technology. An acquirer-in-a-box offering may cover a wider set of merchant acquiring operations, including onboarding, risk monitoring, disputes and settlement-related workflows. The actual capabilities vary by provider.
No. Payneteasy supplies payment technology, including gateway, orchestration, risk-management and reporting capabilities. It does not provide merchant accounts, aggregate merchants as a payment facilitator or assume merchant settlement risk.
Payneteasy supports connections to a broad range of acquiring banks, PSPs and other payment providers. Whether a specific connection can be used depends on the available integration, the institution's commercial arrangements and its technical requirements.
Deploying an existing white-label payment gateway can take a few weeks, depending on configuration and integration requirements. Launching a complete acquiring service may take several months or longer if regulatory authorisation, acquiring sponsorship or card scheme approvals are required.
For institutions with existing acquiring arrangements, the timeline primarily depends on technical integrations, testing and operational readiness. Technology deployment and regulatory approvals should be planned separately.
Thank you for reaching us. Your request has been sent successfully. We will get back to you as soon as possible.
Message was not sent
