Pismo processes two types of card network authorization messages:
Single-message system (SMS) transactions:
- Online/authorization - Message that contains all the data necessary to authorize and settle the transaction. Since there's no need for additional reconciliation, the platform generates the transaction and financially clears it at the time of initial online authorization.
Dual-message system (DMS) transactions - two messages are necessary to settle the authorization:
- Online/authorization - Message that contains initial information required for an issuer authorization decision.
- Offline/clearing/base II - Message that confirms the first message. The second message is sent later. It contains the additional data the issuer requires to clear and settle the transaction.
In a dual-message scenario, the authorization impacts the account balance immediately. However, the transaction records are generated only after confirmation.
It is possible that only the offline/clearing message is received. If the Pismo platform receives a confirmation message from the acquirer that doesn’t link with any authorization record, the platform creates a new authorization record in the account for that message.
The clearing/base II reconciliation process is a central part of the card network authorizations workflow. The reconciliation is responsible for confirming a transaction and posting it to the account. Once the platform confirms an authorization, it triggers other flows within the platform, such as invoice and accounting postings.
The Pismo platform connects to the card network to check if any files are available for processing.
- Mastercard - Pismo processes the settlement files every two hours.
- Visa - Pismo processes the settlement files once a day.
When a settlement file is available, Pismo:
- Downloads it from the card network
- Parses each message within the file, removes any sensitive data
- Issues a raw event for each authorization inside the settlement file. The event includes data from the message that is consumed by the impacted APIs. The platform uses this data to process the confirmation or cancellation of the transaction within the authorizations workflow.
The Pismo platform sends the settlement file to you in two different and complementary ways: via a consolidated file and via events.
The Pismo platform sends you the same consolidated file received from the card network via the file flow. This clearing file contains all transactions that need to be settled. This file contains only an aggregate of the values of the transactions and the receivable or payable interchanges on each day.
- For Mastercard, this is the
- For Visa, this is the
EP747file that contains the VSS reports.
The Pismo platform streams each line of the settlement file in JSON format messages via real-time event notifications. For instance, if the file contains five purchases and three second presentments, eight events are sent. All generated messages are sent to you through clearing events (such as raw_credit_visa, raw_credit_mastercard, or raw_debit_mastercard) and other generated events related to authorization, transactions, and impacts on the limit/balance of the account. For more information on the events, see authorization events.
The events do not contain any totals; only consolidated files do.
- Do not contain sensitive data.
- Follow the field structure that the card network makes available in its manuals.
- Only contain the
cardHashof the card as the cardholder identifier.
- If an issuer transaction is present in the database but is missing in the clearing file after 10 days, it must be canceled.
- If a transaction is missing in the issuer database but is present in the clearing file, then it must be cleared.
- If confirmation comes after cancellation, the authorization can be reopened.
- If a cancellation message is received and the purchase is open, an authorization is canceled.
In a dual-message scenario, the platform performs the reconciliation between the authorization and the clearing/base II message at the time of clearing/base II. At that time, in addition to the transaction generation, there may be changes in authorization values.
To start processing the message, the Pismo authorization platform needs to identify the corresponding original authorization for this message. To do so, the platform compares and verifies message data, such as authorization code and retrieval reference number. After this verification, the original authorization may or may not be identified. For each scenario, the processing is different.
The platform accepts every message received from clearing/base II. Therefore, when an authorization is not linked to the received message, a new authorization is posted to the account. There can be two scenarios in this case: debit clearing adjustment and credit clearing adjustment.
In the debit clearing adjustment, when the Pismo platform receives a confirmation message and this message is not linked to any original authorization, the platform creates a new authorization, and posts debit into the account, decreasing the account balance. Since this is the process of clearing/base II, the transaction is accepted and posted without any additional validations on the card or the account.
In the credit clearing adjustment, when the Pismo platform receives a cancellation/credit message and this message is not linked to any original authorization, the platform creates a new authorization, and posts credit into the account, increasing the account balance.
When the original authorization is found, the Pismo platform performs verification whether to perform reconciliation from the received message. The platform doesn't process the clearing/base II messages in the following scenarios.
- Second presentments messages, where there is an open dispute about the purchase.
- Confirmations of split authorizations, where the message is for an installment other than the first.
- The message is earlier than the last clearing/base II recorded for that authorization. This can happen in a reprocessing scenario for old messages.
- Purchase confirmation that was canceled by the clearing/base II on the same day. In this scenario, the cancellation takes precedence.
- Cancellation of an already canceled purchase.
- Partial cancellation of a pending purchase. In this scenario, the message goes back to the queue to wait for the purchase to be confirmed.
Once the platform determines that the message should be processed, it processes the message and performs the reconciliation. The following shows reconciliation scenarios for confirmation and cancellation messages.
This is the most common reconciliation scenario, where the clearing/base II message confirms a pending purchase. In this scenario, the platform accepts the amount received in the reconciliation message. If there is a difference in the value calculated by the online authorization, the platform reflects this difference on the account as debit or credit. The platform posts the transaction in the amount received in clearing/base II.
- Scenario: Authorization is $100, and clearing/base II confirms $100.
In this scenario, the platform confirms the authorization and there is no additional impact on the account. The platform generates a $100 transaction.
- Scenario: Authorization is $100, and clearing/base II confirms $90.
In this scenario, the platform updates the authorization to $90, posts a $10 credit to the account, and generates a $90 transaction.
- Scenario: Authorization is $100, and clearing/base II confirms $110.
In this scenario, the platform updates the authorization to $110, posts a $10 debit to the account, and generates a $110 transaction.
It is possible to receive a new confirmation message for a purchase that has been confirmed already. In this scenario, the second confirmation message is summed up with the first one. The platform reflects the new amount on the account and generates a new transaction in the value of the second confirmation message.
- Scenario: Authorization is $100, the first clearing/base II message confirms $60, and then the second clearing/base II confirms $40.
In this scenario, with the first confirmation message, the platform updates the authorization to $60, posts a $40 credit to the account, and generates a $60 transaction. With the second confirmation message, the platform updates the authorization to $100, posts a $40 debit to the account, and generates a $40 transaction.
When a purchase has been canceled already and the platform receives a confirmation message for this purchase, the platform reopens the purchase, posts the corresponding amount to the account, and generates a new purchase transaction in the amount of the confirmation message.
- Scenario: Authorization of $100 is canceled, but then the platform receives a confirmation reopening the purchase in the same amount.
In this scenario, the platform reopens the authorization, changes its status from canceled to confirmed, posts a $100 debit to the account, and generates a new $100 transaction.
- Scenario: Authorization of $100 is canceled, but then the platform receives a confirmation reopening the purchase with another amount, $90.
In this scenario, the platform reopens the authorization, changes its status from canceled to confirmed, updates its value to $90, posts a $90 debit to the account, and generates a new $90 transaction.
If the platform receives a confirmation for a previously denied purchase, the platform accepts the reconciliation. The logic follows the same pattern as in the confirmation of a canceled purchase scenario.
In this most common cancellation scenario, the platform receives a cancellation message for an open pending or confirmed purchase. The platform cancels the purchase and posts credit in the total purchase amount to the account. For the previously confirmed purchase, the platform posts a cancellation transaction. For pending purchases, as there was no previous confirmation, the platform doesn't post any transactions.
- Scenario: Cancellation of an already confirmed $100 authorization.
In this scenario, the platform cancels the authorization, posts a $100 credit to the account, and generates a $100 cancellation transaction.
- Scenario: Cancellation of a pending $100 authorization.
In this scenario, the platform cancels the authorization and posts a $100 credit to the account. The platform does not generate any transactions.
This scenario occurs when the platform receives a cancellation message with a value lower than the total purchase amount. In this scenario, the platform keeps the purchase open, issues credit in the cancellation amount to the account, and generates the cancellation transaction.
- Scenario: Authorization of $100 with the cancellation of $50.
In this scenario, the platform keeps the authorization open, issues a $50 credit to the account, and generates a $50 credit transaction.
- Scenario: Authorization of $100 with two cancellations of $50.
In this scenario, the platform keeps the authorization open, issues two credits in the amount of $50, and generates two $50 credit transactions.
The installment purchases follow the same rules as the previous scenarios, with the only difference being that transactions are generated for all installments. In the case of total cancellation, the platform generates cancellation transactions for all installments. In the case of partial cancellation, the platform generates credit the same way as for a cash purchase, with no impact on the generated installment transactions.
International purchases have the purchase amount calculated for the cardholder's currency using the exchange rate of the day of online authorization. For example, if a purchase was made on the 1st of the month and the clearing message arrived on the 10th, the platform uses the conversion rate from the 1st of the month.
International purchases also follow the same rules as the previously described scenarios. In the case of partial cancellation, the platform generates credit the same way as with the local purchase, only considering the credit amount converted to local currency.
The Pismo platform supports any sequence of processing. It is possible to have scenarios such as:
Authorization > Confirmation > Cancellation > Confirmation with a new value
Authorization > Confirmation > Cancellation > Confirmation with a new value > Partial cancellation
Authorization, confirmation, cancelation, and partial cancelation can happen in any plausible order, as long as it is taken into consideration that the platform does not process the clearing/base II messages in certain scenarios, as described at the beginning of this section.
Updated 2 days ago