DCC Transaction Flows

Cardholder Present

  1. The PMS/POS sends a request transaction with the transaction amount, the transaction type (i.e., authorization, sale, refund, etc.) and other required data to the Payment Application.

  2. The Payment Application receives and parses the inbound message.

  3. The Payment Application interacts with the cardholder to get the full transaction amount (i.e., get TIP and cashback amounts and total amount approval).

  4. The Payment Application interfaces to the PIN Pad and cardholder to get the card account data.

  5. If Visa or MasterCard account and DCC is enabled, the following steps should be performed:

    a. Send Fusebox the Eligibility and Rate Inquiry message (transaction type 46).

    b. If the card is not DCC eligible, the payment application will continue as they do today with one minor change, setting DCC fields 151 and 169 appropriately (see API samples).

    c. If the card is DCC eligible, the payment application should interact with the cardholder to see if they want to opt-in to DCC. If they say ‘no’, the payment application performs the normal authorization in the base currency only setting DCC fields 151 and 169. If they say ‘yes’, the payment application will update the transaction with DCC data and continue the card processing flow, (see API samples).

  6. The Payment Application continues with the remainder of the EMV/magstripe processing as they do today. When all data is captured, the Payment Application sends the completed Elavon Gateway API transaction request message to Fusebox for processing.

  7. Fusebox processes the inbound request message and sends/receives the message with the merchants’ TPP host and returns the response to the Payment Application.

  8. The Payment Application completes the transaction processing with the PIN Pad’s and returns the completed transaction message to the POS.

  9. The POS prints the receipt showing the cardholder opted in to DCC and the DCC data elements.

transaction flow for cardholder present

Cardholder Not Present

This scenario might occur if a cardholder has already opted-in to use their country currency rate and the merchant has it on record (e.g., recurring billing) or to be used for a lodging incremental transaction where the cardholder has already opted-in.

  1. The PMS/POS sends a DCC Eligibility and Rate Inquiry message (transaction type 46) to Fusebox with the card’s token.

  2. If the card is DCC eligible, the DCC converted amount and other data will be returned to the payment application.

  3. The PMS/POS can use the converted amount and DCC data returned to the eligibility message to send the financial message on to Fusebox, as they would today (see API samples).

  4. Fusebox processes the inbound request message and sends/receives the message with the merchants’ TPP host and returns the response to the PMS/POS.

transaction flow for cardholder not present