Secondary authorizations

Secondary Authorization Transaction vs Normal Transaction Flow

A key feature that Berkeley offers is the Secondary Authorization. This allows our clients to set custom rules while approving transactions.

In the standard authorization model, the transaction is approved at the processor level after doing all the necessary card validations.

Secondary Authorization Transaction Flow

If Secondary Authorization is enabled on a client program, then there are additional legs to the transaction. The transaction will still go through the various card validations at the processor level. Once this is completed, the authorization request is sent to the client for a final decision. Clients can choose to authorize or decline transactions based on their customer business logic or cardholder preferences.

Use Cases

There are multiple use cases, where a client may choose to implement secondary authorizations. A few examples are mentioned below:

Clients may retain the customer balances on their systems. In such cases, the system would perform all card validations and pass on the transaction request to the client to perform balance checks.
Clients may offer their customers the ability to control where / when their cards can be used. Since this would be different for each customer, the client can use secondary authorizations to validate the rules at a cardholder level, prior to approving the transaction.

These are just a few examples and there are other use cases which can be enabled based on business requirements.

Transaction Flow & Messages

Clients opting for secondary authorization will receive transaction messages from Berkeley and need to build the capability to receive, process and respond to these requests.

High Level Flow

Berkeley uses the industry standard dual message system for card transaction processing. This means that they will be two transactions:

1st - Real Time Authorization

This is a real time transaction that will be sent to the client. As part of this transaction, clients should run their rules and then block the amount / update the amount in the customer's account for successful transactions. It is critical that the amount is blocked at this stage to ensure that the card does not go into a negative balance.

A real-time response has to be sent for authorization requests, else the transaction will be declined.

Message Types (MIT) that clients have to support:

Message Type Indicator (MIT)	Message Type	Description
001	Authorization (most common type)	Card is used for a transaction. Could be a pre-auth, auth, ATM, balance inquiry,…etc.
0110	Authorization Response	Request response to a point-of-sale terminal for authorization for a cardholder purchase
0120	Authorization Advice.	They might not affect the OTB. This could be forced posts, completions, tokenization updates, etc. These cannot be declined.
0400	Reversal	A reversal of a previous auth. Should reference a previous transaction, but it is not required to.
0420	Reversal Advice	They might not affect the OTB. This could be force posts, completions, tokenization updates, etc. These cannot be declined.

Reversal Request. Sent in the following scenarios:

Receiving a reversal request from MasterCard.
Client does not respond in time to an authorization request sent by Berkeley.
Receiving a negative acknowledgment from MasterCard.
Validate against customer rules.

However, recommendation is not to make funds available to customer until settlement is received.

Reversal Advice. Sent in the following scenarios:

Receiving a reversal advice from MasterCard.
Client does not respond in time to a reversal request sent by Berkeley.
Validate against customer rules.

However, recommendation is not to make funds available to customer until settlement is received.

Note: Detailed message specifications will be sent as part of implementation.

2nd - Offline Settlement

This is an offline transaction where the actual money movement happens. Clients will receive a settlement file with all the successful transactions from Berkeley. Once this is received, clients should match the settlement against authorizations. For successful transactions, the hold should be released and the money should be debited from cardholder accounts.

Note: Clients should build a mechanism to identify and address partial match cases. Berkeley will provide fields to enable authorization to settlement matching.

Expired Authorization / Manually Canceled Authorizations, there may be cases where the merchant does not process the settlement transaction within the stipulated time. In such cases, the system will purge the pending authorization transaction after N number of days. The purge period will vary by type of transaction and is maintained at the processor level.

On a daily basis, Berkeley will provide a list of expired / canceled authorizations to the client. Clients should upload the file and drop the matching authorization from their own systems. Cardholder balances must be updated to reflect that the authorization has been dropped.

Things to Consider:

While secondary authorizations offer extra capabilities for your program, there are key things to consider before you enable this service. By enabling secondary authorizations, you become part of the payment transaction. It is therefore essential that your systems do the following:

Be available 24 x 7 x 365.
Be able to receive and respond to authorization requests within milliseconds. The end-to-end turnaround time for a transaction should not exceed 1 sec. Otherwise, it might lead to transaction declines.
Be able to manage multiple simultaneous authorization requests.
Be able to manage the transaction volumes (as per your business plans and growth).
Save the fields required to match authorization with settlement against each transaction.

While matching and dropping authorizations, we recommend not deleting the authorization record, but to change the status of the authorization so that it no longer is an active transaction. This will help you address customer service queries. For example, clients can change the status of an authorization to ‘Matched’, once the settlement has been received.

If you are managing balances, build a robust internal mechanism to block money as part of the authorization flow, until the transaction is either settled or canceled subsequently. You will also have to build the ability to adjust balances based on advice / reversal transaction messages.

When building authorization rules, focus on efficiency and speed to ensure fast response times. We recommend against creating complex rules that take too long to process and will eventually decline the transaction.