This is a guide on integrating with Pismo using the Zero balance integration model

Existing Zero balance documentation:

• Full balance versus Zero balance integration - Contains a table summarizing the differences between Full and Zero balance integration. Further details about the different functionality is also provided.
• Full and Zero balance workflows - Details the differences between Full and Zero balance workflows for card authorization
• Zero balance validations and anti-fraud webhook - Specifications for the Zero balance webhook called during authorization that allows Zero balance clients to do their own validations and anti-fraud checks.

Zero balance webhook

One of the most critical integration points for Zero balance clients comes when transaction authorization is requested in real time. The response has to be fast and accurate (2 seconds max) and adhere to network standards. Your response needs to be automated with low application and network latency.

The client webhook call contains important business information: date, IDs, amount, operation type, merchant, if CVV was validated, if chip was validated, if there is a recommendation to deny and so on.

If your system already has logic to capture and interpret incoming authorizations, it is common to convert Pismo’s webhook request into a format your system can interpret. Likewise, it may be useful to have a formatter to transform your system's response to Pismo’s response format.

If your system does not have authorization processing logic yet, then directly interacting with Pismo’s webhook request and response formats makes more sense.

Issuer webhook logic

Before replying back to an authorization request, either to approve or reject, your validations and checks should be done in a logical order. One way to determine that is is to look at the existing rejection reasons and criteria associated with your card network.

You logic should minimize the need to make unnecessary validations or processing. For example, there is no need to validate a transaction if the account is blocked or not in a valid/active status. Another is to look at Pismo's request and see if you agree with what was passed. For example, if you are receiving a card chip transaction and the chip validation failed, you can probably reject this authorization without further processing.

Other considerations:

• Permitted authorization - Assess if there are any rules that would prevent the authorization, such as a Merchant Category Code (MCC) that you do not accept
• Balance - Assess if the client has enough balance/limit to perform the authorization; for regions with partial authorization, passing the available balance/limit in the reply may be mandatory
• Anti-fraud and anti-money laundering - Run additional checks to validate authorization legitimacy.

Single and double message system considerations

Most modern product implementations use the double message system (DMS), though single message system (SMS) still exists in the market. A dual message system is a payment processing method that sends two messages to process a transaction, while a single message system sends one message.

When an authorization is approved in a double message system (DMS), it does not necessarily mean that it is confirmed. Only a Clearing/Base II file confirms an authorization. It is your responsibility to place a hold on an account's available balance/limit until confirmation is made, otherwise there is a risk that the account holder will spend funds without a correct balance/limit.

For most card networks, confirmation arrives between 8-10 days after an authorization is approved. If a confirmation does not arrive, the standard practice is to revert the hold on account balance/limit.

Please note that a Clearing/Base II file may arrive after the usual time and you are expected to make best efforts to post/collect the transaction. It is also possible to receive confirmation for transactions that the authorizer did not approve or has different values. In these cases, the issuer is also expected to make best efforts to post/collect the transaction.

In single message systems (SMS), this flow is simplified as the authorization already constitutes settlement confirmation.

Accounting and regulatory reports

When working in Zero balance mode, Pismo has a limited view of the issuer’s balance data. Therefore, it is the issuer’s responsibility to ensure proper accounting is taking place.

It is important to control and take into consideration (credit or debit, non exhaustive list):

• Available balance/limit
• Authorizations
• Reversals
• Chargebacks
• Fraud
• Confirmed transactions
• Taxes
• Fees