Online to Issuer (O2I) Flow

The P2 Card Platform - leveraging its Card Processor component - is able to capture and process transactions from the major card networks/schemes:

• Diners Card International (DCI)
• Mastercard
• Visa

Every transaction, after being received from the card scheme, enters a workflow that allows the transaction to be validated before confirmation:

• syntactic correctness verification of the transaction
• semantic correctness validation of the transaction
• verification of the card's existence and status
• verification of the merchant where the transaction was executed
• compliance with the business rules activated by the Issuer

At the end of the process, the Issuer is notified regarding the transactions that were blocked in the process just described. Alternatively, if the transaction is found to be correct and compliant, the Issuer is involved in the authorization process, with the aim of allowing the transaction to be confirmed.

Every single transaction is classified as:

• Financial:
  • Authorization: request for proceed and confirm the transaction
  • Authorization Advice: notification related with an authorization
  • Reversal: cancel a transaction already completed
  • Reversal Advice: notification releated with a cancelled transaction
• Non-financial:
  • Inquiry: request of information (ex. account balance, usually requested by ATM)
  • PIN Management: change or lock of PIN (usually requested by ATM)

Workflow steps

As mentioned, every transaction received from the card scheme is validated before reaching the Issuer. Below is a comprehensive list of all the possible checks the platform is capable of performing before contacting the Issuer.

Not all checks are performed for every action, but it is very important to understand their function in order to determine "if" and "when" the Issuer is involved in the process:

• PAN Luhn Check: The Card Number (PAN) is verified using the Luhn algorithm. If this check fails, the transaction is immediately rejected and will never reach the Issuer.

• BIN Range Check: The Card Number (PAN) is evaluated based on the "BIN Range" to determine the card's Issuer. If the check fails or the Issuer cannot be determined, the transaction is rejected and will never reach the Issuer.

• MCC Check: The MCC (Merchant Category Code) is verified and compared against known and permitted codes. If an MCC is unknown or blocked by the Issuer, the transaction is automatically rejected and will never reach the Issuer.

• Card Check: Verifies if the card exists and is recognized. If this check fails, the transaction is automatically rejected and will never reach the Issuer.

• Card Data Check: The following card information is verified: Status (Active, Blocked, etc.), card expiration date, and consistency of the expiration date with the transaction execution date. If this check fails, the transaction is automatically rejected and will never reach the Issuer.

• CVV Check: CVV1 or CVV2 (if present) are validated. If this check fails, the transaction is automatically rejected and will never reach the Issuer.

• IAV/AVV Check: IAV or AVV (if present) are validated. If this check fails, the transaction is automatically rejected and will never reach the Issuer.

• PIN Check: The correct PIN entry (on a POS or ATM) is validated, and a check is performed to see if the maximum number of entry attempts is over the allowed limit. Each incorrect PIN entry increments the attempt count, up to the maximum. In this case, reaching the maximum number of entry attempts is reported to the Issuer as an Advice. The number of failed attempts is automatically reset at midnight.

• EMV Data Check: The card's "cryptogram" is verified, if present. Optionally, the CVR and TVR values are examined and verified. If the check fails, the transaction is rejected, and the failure is forwarded to the Issuer as an Advice.

• Strong Customer Authentication (SCA) Check: A series of checks are performed to ensure the transaction complies with the requirements of PSD2 (Payment Services Directive 2, a European Union regulation that defines a set of rules for "Strong Customer Authentication"). If the check fails, the transaction is rejected, and the Issuer is notified via an Advice.

• Business Rule Engine (BRE) Check: The transaction is validated by a set of rules defined at the Card Processor level. Each business rule may lead to the transaction being rejected; in this case, the Issuer is notified via an Advice.

• Online to Issuer (O2I): Represents the final step of the process. The Issuer is notified regarding the incoming transaction. At this point, it is the Issuer's responsibility to confirm or decline the transaction that has successfully passed all preceding steps; this operation can be performed by following the technical specifications defined by the integration with P2 Card Platform.

Authorization Flow

The Authorization process involves the validation and confirmation (or rejection) of a card transaction requested by a POS (physical or virtual) to the Issuer. Below is the pipeline of checks performed:

Advice Flow

The Advice process (related to both Authorization and Reversal) is initiated by the Card Processor and refers to transactions that have already been processed previously. The number of checks is significantly lower than those performed for the main flows:

Reversal Flow

The Reversal process is the cancellation of a transaction that has already passed and been approved during the Authorization phase. The number of checks performed is lower than that of the reference process:

Information Flow

The information request flow is initiated only in some specific cases:

• PIN Management: The cardholder can use an ATM to change or unblock their PIN. If the Issuer is interested in receiving this information, it can be transmitted by the Card Processor.
• Transaction Expiry: A scheduled process is executed once a day with the task of identifying transactions that do not correspond to the declared type, and thus cannot be processed.

Inquiry Flow

Inquiry messages are currently supported only for retrieving the balance of the account associated with the card:

Invoke of "Online to issuer" (O2I)

This represents the final step in the transaction processing cycle; it is only initiated if all the checks described previously have a positive outcome, and it directly involves the Issuer for all card transactions attributable to that Issuer.

The original transaction information is transmitted to the Issuer through a single REST/API call that expects a response in a specific format. The outcome of the response is definitive:

• The transaction must be confirmed
• The transaction must be declined

Transaction message incoming into the Issuer

A transaction message always has the same format for all the flows described and, generally, is forwarded to the Issuer only when it has passed all the checks set in the previous steps.

Its content is designed so that a single transaction can be entirely validated based on the information present in the message itself. For this reason, the request sent to the Issuer will include (among others) the following information:

• Unique transaction identifier
• Reference to a previously processed transaction (if required by the flow)
• Transaction date and processing date of the same
• Transaction amount and currency
• Charged amount and currency
• Identifier of the terminal where the transaction was generated
• Various information related to the merchant where the transaction was carried out
• Identification token of the reference card and associated card scheme
• Transaction type

A complete list of fields with their descriptions is provided in the REST API documentation for the endpoints that allow the "simulation" of the various types of calls to the Issuer: incoming message details

Matrix of fields: required, optional or missing

For every action executed by the Card Processor, which is received by the Issuer, some values are provided as input, within the JSON body of the message. Below is a table showing:

• R: Required - Field is always provided for the given action
• O: Optional - Field can be provided for the given action
• R: Missing - Field is not provided for the give action

Fields	Authorization	Advice	Reversal	Information	Inquiry
CardScheme	R	R	R	R	R
VirtualCardNumberId	O	O	O	O	O
Type	R	R	R	R	R
TransactionId	R	R	R	R	R
RefTransactionId	O	O	R	M	M
Stan	R	R	R	R	O
Source	R	R	R	R	O
CardToken	R	R	R	R	R
Authentication	O	O	M	M	M
AuthenticationProtocol	O	M	M	M	M
ScaExemption	O	M	M	M	M
TransactionDateTime	R	R	R	O	R
ProcessDateTime	R	R	R	O	R
TransactionAmount	R	R	R	M	M
TransactionCurrency	R	R	R	M	M
BillingAmount	R	R	R	M	M
BillingCurrency	R	R	R	M	M
Mcc	R	R	R	O	O
TerminalId	O	O	O	O	O
MerchantId	R	R	R	O	R
MerchantName	R	O	O	O	O
MerchantStreet	O	O	O	O	O
MerchantCity	O	O	O	O	O
MerchantZip	O	O	O	O	O
MerchantCountry	R	O	O	O	O
Wallet	O	O	M	M	M
ResponseCode	R	R	R	M	R
AuthorizationCode	O	O	O	M	O
EntryMode	R	O	O	O	O

Confirmation/Reject of a transaction, outgoing from Issuer

When the Issuer is involved in the process (for Authorization, Advice, Reversal, Inquiry), it must provide a response to the P2 Card Platform based on a specific schema containing the following data:

• TransactionId (string): Mandatory, must be the same transaction number received as input and originally sent by the Card Processor. The purpose is to allow for a match between the request and the response.
• BalanceAmount (decimal|bigdecimal): This is the amount available in the account associated with the card. This data is mandatory only for Inquiry actions.
• BalanceCurrency (integer|short): Represents the currency of the balance provided with the "BalanceAmount" field, according to the numeric ISO 4217 code. This value is required only for Inquiry actions.
• ResponseCode (string): Always mandatory. The Issuer's response code to the action submitted by the Card Processor. Its value must be one of those listed below.

Response codes provided by Issuer

Fields	Description	Authorization	Advice	Reversal	Information	Inquiry
OK	Approved or completed with success	x	x	x	x	x
CRGUI	Insufficient funds or transaction beyond limits	x	-	-	-	-
EXDCL	External decline	x	-	-	-	-
TRXNS	Invalid transaction	x	-	-	-	-
SYSEX	System exception	x	-	-	-	-

Endpoints exposed by Issuer and invoked by P2 Card Platform

When the Card Processor reaches the point of involving the Issuer in one of the flows described above, it will execute an invocation to a specific REST/API endpoint exposed by the Issuer itself. Since different types of actions are expected, all of which receive the same data schema as input and must issue the same response structure, it is necessary to expose separate endpoints:

• Authorization: it usually has a partial URL that matches /authorization. It is used to complete the "Authorization Flow".
• Reversal: it usually has a partial URL ending with /reversal. It is invoked upon the request to cancel a transaction that was already submitted.
• Advice: It usually has a partial URL ending with /advice. Its purpose is to receive notifications (advice) related to "authorization" or "reversal".
• Inquery: It usually has a partial URL ending with /inquiry. Its purpose is to manage both the flows defined for "inquiry" and for "information".

Every endpoint is invoke using an HTTP method POST, and a request with content type application/json; charset=utf-8 will be provided. Also the response generated by Issuer should have content type application/json; charset=utf-8.

Every single URL exposed by the Issuer must be configured in advance within P2 Card Platform, providing a corresponding API Key (in headers or querystring) that allows the Issuer to recognize the caller.

Furthermore, considering that these endpoints are a fundamental part of the transaction authorization process, it is suggested to limit the access to the API using a restriction based on IP Filtering.