Recently, I had the opportunity to examine in detail a Partial Authorization transaction that came to us as an Issuer.
We can briefly describe Partial Authorization as "Being Partially Approved Instead of Being Declined".
Usually, during a card transaction, if the account balance is lower than the transaction amount, we see a message saying it was declined due to insufficient limit.
Behind such transactions there is often a sale lost by a small margin, a ruined customer experience and a drop in the approval rate on the acquirer side. As a smart solution to this problem, Partial Authorization, that is, the partial approval structure, comes to the rescue.
What is this "Partial Authorization"?
In simple terms:
If the cardholder's account or credit limit does not have the full transaction amount, the issuer (the card-issuing bank) approves only the available amount instead of declining the transaction entirely.
It allows the remaining part to be completed with a different method, such as another card, a digital wallet or cash.
Example:
A purchase of 150 TL is being attempted, but the card has only 141 TL.
Normally the system would decline the transaction with error code 51 - Insufficient Limit.
With partial auth, it approves 141 TL and asks for the remaining 9 TL to be paid by another method.
In other words, a mechanism that says "if you can't pay the whole amount, use what you have anyway."
Where did this need come from?
There are two major reasons behind it:
- Reducing declined transaction rates:
The card limit is full, the balance has dropped, or a small difference is left on a prepaid card. Instead of declining the transaction, partial auth makes it possible to salvage the amount up to the balance/card limit. - Protecting the customer experience:
A message like "Your balance is X TL, would you like to pay the rest with another method?" instead of "Your card was declined" makes a big difference for the customer.
So how does it work technically?
As you know, the authorization message works as ISO 8583.
When a terminal or an e-commerce application sends a payment request, the following fields play a critical role:
- DE 4 – Transaction Amount: The requested amount
- DE 60.10 – Partial Authorization Indicator: (On the Visa side) the flag meaning "I support partial approval"
- DE 39 – Response Code: If the issuer gives a partial approval, the code here is 10 → "Approved for partial amount"
- DE 54 – Additional Amounts: In some systems, the approved amount is specified here.
The transaction flow is as follows:
- The customer enters 150 TL on the POS.
- The acquirer sends this request to the issuer.
- The issuer checks the balance, and if there is 141 TL, approves that amount and returns DE 39 = 10.
- The POS asks for an alternative payment for the remaining 9 TL.
Simple but powerful logic. Keeping the transaction alive, even partially, and increasing customer/merchant satisfaction.
Of course, for the above structure to work, the acquirer, the issuer and the POS software must all support this feature.
Is it mandatory or optional?
First of all, let us state that partial auth is not a requirement.
Although schemes such as Visa and Mastercard present it as "recommended to support", no bank or acquirer is obliged to use it.
For this transaction to be approved, the Issuer and the Acquirer must both know about and recognize this transaction. If the acquirer side does not support it, the POS will not understand it even if the issuer gives a partial approval.
In this case, the transaction will still end in the classic way, with a "51 – Insufficient Limit/Balance" error.
Why does Partial Auth matter from a business perspective?
Because "partial approval" is not just a technical feature, it is a commercial opportunity as well.
Let us explain with an example:
A customer wants to make a purchase of 300 TL.
The card has 280 TL.
- Normally: the transaction is declined, and the sale is lost.
- With partial auth: 280 TL is approved, the remaining 20 TL is paid with another card, and the sale is completed.
Result:
- The customer completes their shopping.
- The business saves its sale.
- The bank increases its approval rate.
In other words, "everyone wins", "the buyer is happy, the seller is happy."
Are there country and scheme differences?
In markets such as the US, this model has been actively working for years.
It is widely used because POS manufacturers, acquirers and payment gateways are configured accordingly.
Visa's Partial Authorization Service and Mastercard's Split Tender solutions provide support in this area.
In some countries this structure is limited because of regulation, accounting and customer rights. In short, not every country is at the same point.
For example, in Europe many banks maintain the principle that "if the customer has not approved the full payment, the transaction should not start."
In Turkey, since POS infrastructures and bank systems do not yet have a structure that fully supports it, we can say it is not very widespread.
However, with the spread of e-commerce, prepaid cards and mobile wallets, we can say this topic will be discussed more in the coming years.
ISO 8583 (Summary Table)
| Field | Name | Role in Partial Auth |
| DE 4 | Transaction Amount | Requested amount |
| DE 39 | Response Code | 10 = Approved for partial amount |
| DE 54 | Additional Amounts | Approved amount (optional) |
| DE 60.10 | Partial Auth Indicator | Terminal/acquirer support signal |
| MTI 0100 / 0110 | Authorization Request / Response | Main message flow of the transaction |
ISO 8583 Field Map (Partial Authorization Flow Diagram)
In this flow:
- DE 4 → the monetary field of the transaction request (used in both request and response)
- DE 39 → indicates that the issuer gave a partial approval (10)
- DE 54 → carries the actual approved amount
- DE 60.10 → is the signal that the acquirer side says "I support partial auth"
In other words, if the three components of the system (POS, acquirer, issuer) interpret these fields correctly, the partial approval process runs without problems.
In short, partial authorization reminds us of something simple but deep:
“Starting somewhere, even if everything is not complete, is better than never starting.”
It is the same in payment systems.
Partial approval is a small but effective touch that saves both sales and the user experience.
What will the outlook for the future be?
Partial authorization is not just a "backup plan", it is actually a smart payment strategy.
In the age of prepaid cards, multi-balance management and digital wallets, this model
challenges the "insufficient balance = declined transaction" equation.
In the future, in hybrid systems where card, account and wallet balances are merged, AI-based payment engines will manage partial approvals automatically. The user will not even notice, but in the background the system will say "I completed the rest from this account."
What do you think, will there be an explosion in Partial Auth transactions with Agentic Commerce?
