Diagram of a partial authorization where an issuer approves only part of the requested amount

General Definition and Business Model

Partial authorization allows part of the requested amount to be approved when the card does not have the full balance/limit, with the remaining amount paid by another method.
It can be used especially in variable-amount transactions such as prepaid and debit cards, fuel stations, supermarket POS and e-commerce.

What Are the Technical and System Requirements?

a. Authorization Flow

  • In the ISO 8583 message, the DE54 – Additional Amounts field must be active. The issuer returns the approved amount in this field.
  • The DE39 response code must be “10” (Partial Approval).
  • DE4 (Transaction Amount) and DE54 (Authorized Amount) can differ; this difference is taken into account during clearing.
  • The authorization host system must interpret this amount difference correctly and drop the old assumption that “full approval = equal amounts.”

b. POS Terminal and Application

  • The POS software must have a “partial authorization enabled” parameter.
  • The terminal must correctly interpret the “partial approval” code returned by the issuer and show the cashier/customer the following message:
    “X TL was approved on your card; please choose another payment method for the remaining Y TL.”
  • The POS must be able to support two separate payment acceptances (for example card + cash).
  • In EMV terminal certification, this feature may count as a “major change” → a re-certification process with the manufacturer may be required.

c. Online / E-Commerce

  • The partialAuth=true parameter must be supported in gateway APIs.
  • The approved and missing amounts must be clearly shown in the customer interface.
  • The merchant system must be able to complete the remaining amount with an alternative payment (card, bank transfer, wallet, etc.).

Receipt (POS Slip) Requirements

a. New Fields in the Receipt Format

FieldDescriptionExample
Transaction AmountTotal amount requested250.00 TL
Approved AmountAmount approved by the issuer150.00 TL
Remaining AmountBalance that must be paid by the customer with another method100.00 TL
Approval Code (DE39)Code “10” must be printed as “Partial Approval”“Approval Code: 10 (Partial Approval)”
Information LineGuidance for cashier & customer“150 TL was approved on your card. Please pay the remaining 100 TL with another method.”

b. Points to Watch on the Receipt

  • The above fields must appear on both receipts (customer/merchant).
  • The warning “Transaction not completed – the sale is not closed until the second payment is made.” must be added at the end of the receipt.
  • The POS manufacturer must update the receipt template (the new fields must be added to the XML/TLV format).
  • In e-receipt (digital receipt) deliveries, the same fields must also appear in the e-mail/SMS output.

Clearing and Reconciliation (Clearing & Settlement)

a. ISO 8583 Message Structure

  • DE4 (Transaction Amount) → Total amount requested.
  • DE54 (Additional Amounts) → Amount actually approved.
  • The clearing file must process these fields as separate line items, and these fields must be taken into account when the clearing file is loaded.
  • The “authorized amount < requested amount” scenario must be supported in the acquirer clearing system.

b. Clearing Files

  • A “partial flag” must be added to the clearing files the acquirer sends to the scheme or BKM (Interbank Card Center).
  • The settlement amount must be processed on the authorized amount.
  • The amount to be paid to the merchant must equal the approved amount.
  • New columns in clearing control reports (reconciliation reports):
    • Requested Amount
    • Authorized Amount
    • Partial Flag (Y/N)

c. Reconciliation Process

  • Only the approved amount must be taken into account in reconciliation between acquirer, issuer and merchant.
  • The “amount difference warning” rule in the reconciliation engine must be excluded for partial transactions.
  • “Partial Txn Count / Volume” must be added to the daily reconciliation reports.
  • In reversal/refund processes, only the approved amount can be refunded.
  • If the second payment has not been made, the missing payment must be reported on the merchant side.

Merchant Usage

a. Management via a Standard POS

Yes, the merchant can manage a partial authorization transaction through a standard POS — but the POS software must support this feature.

So, what does the scenario look like?

  1. The cashier makes a sale of 250 TL.
  2. The POS receives a partial approval of 150 TL from the issuer (DE39=10).
  3. The approved amount and the remaining amount are displayed on the POS receipt.
  4. The POS warns the cashier: “collect a second payment for the remaining 100 TL.”
  5. The cashier collects the payment with a second card, cash or QR.
  6. The POS combines the two transactions under a single sale or sends them to the cash register system as a separate line.

Important:

  • If the POS manufacturer or the bank terminal does not support this flow, the partial authorization transaction is declined (even if the issuer responds, the POS does not recognize it).
  • For this reason, as an acquirer, it is essential to update the POS software and renew the certification.

Operational and Reporting Requirements

  • A “partially approved transactions” tab must be added to the merchant portal.
  • In daily reports, Approved Amount and Remaining Amount must be listed in separate columns.
  • Chargeback & refund screens must recognize the “partial approved” status.
  • Training materials must explain the cashier flow (sample receipt + alternative payment process).

Compliance & Certification

  • Compliance tests against the Visa/Mastercard “Partial Approval Program” documentation must be performed.
  • The response code 10 scenario must be added to EMV Level 2 & L3 tests.
  • From a PCI DSS perspective, no new obligation arises as long as the data flow does not change, but a re-assessment is needed for POS/host code changes.

Conclusion

Partial authorization is a feature that, for the acquirer, both increases customer satisfaction and raises collection success.
However, for it to be implemented correctly, the following are required:

  • POS software update,
  • receipt format revision,
  • clearing & reconciliation system updates,
  • merchant training
    are required.