# Partial Approval

The card brands require certain industries to support partial approval, or the ability to approve a transaction for less than the amount requested. Instead of a decline, the card issuer returns an approval for the available funds. The merchant will then request an additional form of payment for the remaining balance.

While partial approval support is required in some industries, it is optional in others, such as e-commerce and lodging. This is based on the merchant category code (MCC), which is assigned by the merchant’s processor. Some merchants choose to support partial approval when it’s not required to prevent consumer dissatisfaction and potential lost revenue.

To enable merchants to accept partial approval, your interface must include the ALLOWPARTIALAUTH API Option in authorization, sale, and capture requests. When doing so, your interface will need to interrogate the amount in the `amount.total` field in the transaction response (comparing it to the amount requested) to determine if a transaction is partially approved. Your interface must be able to capture the remaining balance with a new invoice number and as a new transaction.

### Use Case: Partial Approval

##### Actors: Interface, Clerk, Consumer

##### Preconditions: A merchant supports partial approval.

##### Main Flow: This flow illustrates a partial approval response, resulting in a second transaction using a separate payment card.

1. A [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) request is sent for the full transaction amount. The request must include the API Option ALLOWPARTIALAUTH.
2. Response Code ‘P’ is received with no error codes, and both merchant and consumer receipts are generated. The amount returned in the `amount.total` field is less than the requested transaction amount.
3. The clerk informs the consumer that the transaction was partially approved and requests another form of payment for the remaining amount.
4. The consumer provides another payment card.
5. A [Sale/Purchase](/apis/payments-platform-rest/openapi/transactions/transactionssale) request is sent for the remaining transaction amount using a new invoice number. The request must include the API Options ALLOWPARTIALAUTH.
6. Response Code ‘A’ is received with no error codes, and the `amount.total` field is equal to the remaining transaction amount.
7. Receipts are generated.


##### Alternate Flow 1: This flow illustrates a partial approval resulting in a second transaction using cash.

1. Starting at step 4 of Main Flow: The consumer provides cash.
2. The clerk follows the merchant’s procedures for processing cash transactions.
3. Both merchant and consumer receipts are generated.


##### Exception Flow 1: This flow illustrates a partial approval resulting in a void.

1. Starting at step 4 of Main Flow: The consumer cannot provide another form of payment.
2. Follow steps in Use Case: Voiding an Invoice.


##### Exception Flow 2: This flow illustrates a partial approval when services that have already been rendered and another form of payment cannot be obtained.

1. Starting at step 4 of Main Flow: The clerk has captured a partial payment for services, but the consumer cannot provide another form of payment.
2. The clerk follows the merchant’s procedures for notifying the auditor of the loss.


##### Post Conditions: An approved transaction awaits settlement at the end of the day.