Ecommpay launches partial approval for card payments

Ecommpay, a payment service provider, announced on 30 September 2026 a feature called Partial Approval that lets a card issuer authorise less than the amount a merchant originally requested when a cardholder does not have enough available funds. Instead of the transaction failing outright, the issuer can approve a lower figure, and that lower figure becomes the actual payment taken.

It is relevant to merchants in the UK who process card payments through Ecommpay's Gate API or its standard hosted Payment Page, though the reviewed material does not confirm UK geographical availability, eligible UK merchant categories, or that every UK Ecommpay merchant can activate it; merchants should confirm eligibility directly with Ecommpay. The feature only works where the project has been enabled and the issuer behind the card supports it. It matters now because it changes what a "declined" transaction can mean at checkout, and because it introduces consent and disclosure requirements, set by Ecommpay rather than arising from any new UK law, for any merchant who switches it on.

The core point for UK readers to hold onto is this: a partial approval is not a discount, and it is not full payment. It is a smaller amount than the merchant asked for, chosen by the card issuer, and anything left over has to be collected, waived or reconciled separately.

How the feature works

Under Ecommpay's standard processing flow, a card payment is either approved for the full amount requested or declined. With Partial Approval switched on, a third outcome becomes possible: when the cardholder's available funds are insufficient to cover the full amount, the issuer may approve a lower amount instead, determined under its own processing rules. Ecommpay's technical documentation gives a non-production illustration in which a requested €100 payment is approved for €90 — the figure is an example to explain the mechanism, not a published performance statistic or a guaranteed threshold.

Ecommpay supports the feature for standard Visa and Mastercard payments made through its Gate API or the standard edition of its Payment Page. Two conditions have to be met before it can be used:

• The merchant's relevant project must be enabled for the feature by arrangement with an Ecommpay account manager.
• For each individual payment where partial collection is acceptable, the merchant must set a parameter called allow_partial_approval to true.

Crucially, the issuer decides whether to offer a partial amount and how much, under its own processing rules. The merchant cannot choose the approved figure, and there is no guarantee that any given issuer will support it. Visa's April 2026 public rules show that mandatory participation in Visa's own partial-authorisation service across Europe is limited to specified automated fuel dispenser transactions, so merchants should not assume that every UK-issued card, or every type of transaction, will receive a partial approval even where Ecommpay's own systems support the feature. The packet reviewed for this article did not establish Mastercard's current UK participation requirements.

Where partial collection makes sense — and where it doesn't

Ecommpay points to flexible account top-ups and bookings whose balance can be settled later as the clearest use cases. The logic is straightforward: if a customer is topping up a wallet or balance, crediting a smaller amount than requested still produces a useful, valid outcome. The same is harder to argue for a fixed-price purchase, where collecting only part of the price does not settle the amount owed for the goods or service, and fulfilling the order as though it had been paid in full would misrepresent what was actually collected.

Once an issuer approves a lower amount, that lower amount becomes the actual payment. Any outstanding balance is not automatically chased — a merchant who wants the rest has to raise a separate payment request. Refunds are also capped at the amount actually paid, not the amount originally requested. Merchants adopting the feature need to track both figures — requested and approved — through their own records, because Ecommpay's system will not treat the two as interchangeable.

Consent and disclosure

Taking a different amount than a customer expected to pay raises a consent question, and Ecommpay's own guidance treats it as one. Ecommpay instructs merchants using the feature to notify customers before each applicable purchase that partial approval is available, or otherwise obtain their consent, and then to disclose both the requested and approved amounts once the payment is complete. Merchants are also expected to support a further payment for any balance, provide refunds where needed, and keep track of both amounts throughout.

On its hosted Payment Page, Ecommpay says it builds this into the checkout itself, with a warning label, an explanatory pop-up, and a completion screen that shows both the requested and approved amounts. The documentation does not establish what equivalent interface, if any, merchants integrating directly through the Gate API are given, so those merchants should confirm their own disclosure design meets the same standard.

This sits alongside, rather than inside, UK payment law. Regulation 67 of the Payment Services Regulations 2017 — in force since 13 January 2018 — provides that a UK payment transaction is authorised only where the payer has consented to that transaction or to the series of which it forms part, and sets out how consent to future transactions in a series can be withdrawn. Separately, the Financial Conduct Authority's guidance on recurring card payments, last updated 23 June 2025, says consent to a recurring payment should be clear, specific and informed, including enough detail on amount and frequency for the customer to understand and agree to the arrangement. Neither of these sources refers to Ecommpay's product by name, and nothing in the packet suggests the FCA has reviewed or endorsed this specific implementation. They establish the general UK legal backdrop against which any merchant's consent flow for partial approval should be judged.

Because a partially approved payment still moves money off a customer's card, the usual risks of card spending apply: a customer agreeing to a lower, part-payment is still committing card funds, and any later top-up payment to cover the balance is a separate transaction subject to the same authorisation and consent requirements.

The subscription caveat

Ecommpay's launch announcement names subscription billing among the business models that may tolerate partial collection. Its own technical documentation complicates that claim. It states that the allow_partial_approval indicator is ignored for on-demand and regular card-on-file purchases, and that an insufficient-funds transaction in those documented flows is simply declined, as before. The one exception is the initial payment used to register a card for a future series: that first payment may be partially approved, but doing so does not change the amount that will be collected on subsequent debits in that series.

In other words, Partial Approval does not rescue the documented on-demand or regular card-on-file debits — the specific flows Ecommpay's technical documentation addresses. An initial registration payment may be partially approved, but whether any other subscription-related scenario can receive a partial approval is not established in the material reviewed. Merchants running subscription businesses should treat Ecommpay's broader subscription framing with caution, seek clarification from Ecommpay on which flows beyond those documented are covered, and test the documented behaviour directly rather than assume the feature changes how renewal declines are handled.

What's excluded, and what merchants still have to build

Partial Approval is unavailable through Ecommpay for Click to Pay purchases, Visa Instalments, and purchases made through payment links. It can apply to one-step and two-step purchases and to certain stored-card one-click purchases, subject to the card-on-file limits described above.

Ecommpay's announcement says merchants do not need to change their checkout architecture, existing payment flow or endpoint to use the feature. The technical documentation sets a fuller picture: merchants still need to handle changed request and callback data, track requested versus approved amounts, build in consent and post-payment disclosure, support collection of any outstanding balance, and account for refunds being capped at the amount actually paid. "No separate integration" is best read as Ecommpay's claim about not needing a new API endpoint, not as an assurance that no implementation work is required.

Several practical questions remain open. The reviewed material does not state which UK merchant categories can activate the feature, does not publish a list or proportion of participating UK issuers, and does not disclose any pricing, adoption figures, approval-rate uplift or recovered-revenue data. No launch customer or UK transaction-volume figure has been published.

What to watch next

Merchants considering the feature should go to Ecommpay's own integration documentation for the current technical detail, including the allow_partial_approval parameter and its treatment across different payment flows, and should confirm with their account manager which issuers and card types are realistically expected to support partial approval for their business. Anyone designing a consent flow around the feature should check it against regulation 67 of the Payment Services Regulations 2017 and the FCA's guidance on recurring card payments, since neither source has issued product-specific guidance on partial card authorisation.