Basic flows

Common flows

PURCHASE & PRE-AUTH

Both types of transactions share the same flow of messages, with only the transaction type changing depending on the option the merchant selects. The messages in a flow are linked to each other with the transaction identifier. This identifier is unique for the entire flow, and is required to be sent within every subsequent message. This transaction identifier is received in the AuthorizationResponse message.

To complete a payment the basic messages flow is:

If the merchant requires to print the receipt the basic flow is enhanced with the print messages.

REFUND

Note

Refund transactions only are supported on attended devices.

This transaction type follows the same pattern as the purchase / pre-authorization flow. The difference is that there are two types of refund the CM.com IPP Payments Platform supports:

• Referenced refund:

  • It is always linked to a previous purchase/sale after pre-authorization.

  • To execute a referenced refund successfully, the same card used during authorization must also be used and the refund validity period must be respected.\

  • There is a processor dependent validity period when refunds can be executed. This validity period is usually 30 days.\

  • During a referenced refund the system will take the information pertaining to the initial transaction and examine the amount, currency, date, validity period, card used, number of existing refunds for the original purchase.\

  • Only one referenced refund is allowed for a purchase or sales after pre-auth.

  • In the case of MAT Merchant Approved Transactions., the referenced refunds are not possible.

If the merchant requires to print the receipt the basic flow is enhanced with the print messages.

It is possible that instead of an AUTHORIZATION_RESPONSE (0311) a ABORT (FFFF) is received, the RESULT_CODE indicates the error condition. This happens for example when:

• The refund validity period of the original payment is expired.

• When a refund is attempted on a terminal not authorized to perform refunds.

• When the referenced transaction is not found with the transaction identifier supplied.

Result Code	Description
0x0000	Success
0x0303	Confirmation amount exceeds authorized amount
0x0600	Transaction not found for the indicated STAN or the specified date
0x0F02	Transaction Expired

Refund referenced specific result codes

• Unreferenced refund: it is not linked to a specific previous transaction executed on the CM IPP Payments Platform.
  This type of refund is only supported in the Netherlands. In the Netherlands this type of refund is called 'retour pinnen', and the responsibility of referencing the original purchase/sale after pre-authorization lies with the merchant and/or integrator.

For refunds, the CM.com IPP Payments Platform will send Transaction Options (5FE304 = 0x02), and the merchant is required to print and sign the cardholder’s receipt. Terminals must use the Transaction Options tag to determine receipt generation, printing the refund line in the cardholder receipt.

PRE-AUTH CANCELLATION / CONFIRMATION / UPDATE

This flow is only applicable for a successful pre-authorization, and is used to confirm the amount, update the amount, or cancel and free the reservation of balance on the cardholder’s bank account.

There are two possible scenarios:

• Finalize a Pre-Authorization: Finalizing a pre-authorization involves either capturing the authorized amount for settlement (also referred to as confirming the authorization or completing the sale after the pre-authorization) or releasing the reserved amount on the cardholder’s account (known as pre-authorization cancellation). If a pre-authorization is not canceled or confirmed by the terminal, the CM IPP Payments Platform allows it to expire automatically. The CM IPP Payments Platform allows pre-authorizations to expire automatically. It has a scheduled mechanism that automatically reverses expired pre-auth transactions.

• Update a Pre-Authorization: When using this message to update a pre-authorization, the user can specify an additional amount to increase the initially reserved amount. For instance, if the original pre-authorization amount is 50 and the user submits an update with an additional 10, the total reserved amount will be adjusted to 60. There is no limit on the number of update messages that can be sent by a terminal, nor is there a maximum for the cumulative pre-authorization amount from the perspective of the CM.com IPP Payments Platform. CM.com advises to correctly limit the number of updates to 10 to decrease the chances of approval errors in the payment chain.

The card does not need to be present during the PRE-AUTH CANCELLATION/CONFIRMATION/UPDATE. The pre-authorization CONFIRMATION/UPDATE is only possible within the pre-authorization’s validity period. Based on the merchant’s activity and the card brand used, the pre-authorization validity period varies. Integrators are required to validate the applicable pre-authorization validity period(s) during onboarding and assure they are respected when confirming or cancelling pre-authorizations.

For comprehensive information regarding the Pre-authorization operation request, please click here: PRE_AUTH_OPERATION_REQUEST (0381).

An ABORT message can be the result, when for example the amount specified in the PRE_AUTH_OPERATION CONFIRMATION request exceeds the pre-authorized amount.

Result Code	Description
0x0000	Success
0x0303	Confirmation amount exceeds authorized amount
0x0600	Transaction not found for the indicated STAN or the specified date
0x0F02	Transaction Expired

PRE-AUTH Confirmation specific Result Codes

Result Code	Description
0x0000	Success
0x0600	Transaction not found for the indicated STAN or the specified date
0x0F02	Transaction Expired

PRE-AUTH update specific Result Codes

Result Code	Description
0x0000	Success
0x0600	Transaction not found for the indicated STAN, the specified date, or it may have been previously cancelled or confirmed.

PRE-AUTH Cancellation specific Result Codes

Receipt Printing Flow

The terminal can send a PrintRequest message to the CM.com IPP Payments Platform to receive the PrintCommand with the receipt. If the transaction identifier will be included in the print request message, the receipt attached to the print command will reflect the indicated transaction. If the transaction identifier is not provided, the last transaction receipt will be delivered.

When a wrong transaction identifier has been passed, an ABORT (FFFF) message will be received, with a result code indicating TRANSACTION_NOT_FOUND 0x0600: