Merchants and acquirers can use incremental authorization to add some amount to a previously created authorization to reflect a transaction's real amount.
- Only occurs in the authorization/base I flow.
- Is based on a new authorization request that identifies the original authorization.
- If approved, increments the authorization amounts.
The Pismo platform identifies an incremental authorization differently between the Visa and Mastercard card networks, but the processing is the same.
Note: This feature is for full balance integration only.
When the Pismo platform identifies an incremental authorization, the flow is as follows:
The platform retrieves the original authorization based on the identifier received in the ISO message.
If the platform doesn't find the original authorization based on the identifier received in the ISO message, it handles this request as a new authorization with a new authorization code. Then, the request follows a regular authorization flow. Depending on the validation results, the platform approves or declines this request.
When the platform finds the original authorization, it validates whether this authorization can be incremented or not. To qualify:
- Both the original and the incremental authorization must be the same operation (they must have the same processing code).
- The original authorization must be pending and not be settled by the clearing/base II process.
If the original authorization doesn’t meet these requirements (for example, if it is declined, canceled, or settled), the platform creates a new authorization request that follows regular authorization flow.
Once the platform determines that the authorization can be incremented, it marks the request as incremental and proceeds with the usual authorization flow to validate whether to approve or deny the authorization.
If the incremental authorization is approved, the platform:
- Adds the incremental amount to the transaction.
- Impacts the account limits with the amount of the incremental operation.
- Issues an authorization event with the category set as INCREMENTAL.
If the incremental authorization is declined for any reason, the platform issues an authorization event with the category set as DECLINED.In both approved and denied scenarios, the issued events have the amounts and information of the incremental operation, but the identifiers of that authorization, such as
cid are the same as the original one, allowing the events to be linked to each other.
After being incremented, the authorization usually receives a clearing message to settle this operation with the summed amount of both the original and incremental authorization. All rules for clearing/base II apply to this authorization. It is possible for it to be canceled, partially canceled, or to receive more than one confirmation message. For more information about clearing processing, refer to this page.
Identifying incremental authorization
Visa and Mastercard have different ways to indicate that an authorization request is incremental.
The platform uses the following fields in the Visa request message for incremental authorization processing:
|Field 63.3 – Message Reason Code||When this field contains the value 3900, the platform identifies the authorization request as incremental.|
|Field 62.2 – Transaction Identifier||After identifying the request as incremental, the platform uses the transaction identifier in this field to link the request with the original authorization that is being incremented and follows incremental processing as described here.|
In the Mastercard messages, there is no specific code that identifies an authorization request as incremental. The platform uses the following fields in the Mastercard request message for incremental authorization processing:
|DE 48, subelement 63 (Trace ID)||If this field is populated, it indicates some relationship of this request with an original authorization. The platform uses this value to find and compare it to the value of DE 63 (Network Data) of the related original authorization.|
|DE 63 (Network Data)||If this value in the related original authorization matches the value in DE 48, subelement 63 (Trace ID) in the request message and the request is in a pre-authorization state, the platform identifies the authorization request as incremental and follows incremental processing as described here.|
The platform ignores the trace ID when the value received for the Banknet Reference Number is 999999, since this value can be used only to populate the field without indicating any relationship.
Updated 4 months ago