EMV Receipts

The Gateway API response message returned from Fusebox contains most of the required data elements for receipt printing. There are some elements obtained by the payment application during the 2nd Generate AC completion process that need to be retained by the POS and printed on the receipt. It is the responsibility of the payment application to ensure that all required data, especially any data returned from the 2nd Generate that does not contain cardholder-sensitive data, is sent to the POS for retention and/or receipt printing.

There are two fields to identify EMV elements required to be printed on approvals or declines:

  • 1378 - EMV Approved Receipt Field List

  • 1379 - EMV Declined Receipt Field List

These fields will be populated by the Fusebox TPP interface layer based on the TPP specifications.

Some TPPs require static text to preface this data on the receipt. The Fusebox TPP Interface layer will add any static text after a pipe delimiter (“|“) in fields 1378 and 1379 to accommodate this requirement.

note

The labels are provided for the receipts as a static requirement from the Third Party Processor. Fields not present in the API response need not be printed. The POS/PMS will need to accommodate the presence or absence of those fields presented in 1378/1379.

The following is an example of fields returned for an approved transaction for a TPP that does not require static text:

1378,1326|;1300|;1307|;1325|;

1300,2A29435BF19ACEC13030

1307,0000008000

1325,A0000000041010

1326,Mastercard

1380,C

The following is an example of fields returned for an approved transaction for a TPP that does require static text:

1378,1326|Application Label: ;1300|ARPC: ;1307|TVR: ;1325|AID: ;

1300, 2A29435BF19ACEC13345

1307, 0000008000

1325, A0000000041010

1326, Mastercard

1380,Chip

If the first Generate AC action returns an “AAC” cryptogram instead of the expected online “ARQC” cryptogram, the payment application will not send the transaction to Fusebox, and no TPP-specific API Field 1379 is returned. In that event, we’ve created a generic declined list for field 1379.

1379,1319|Tag 82: ;1307|Tag 95: ;1313|Tag 5F34: ;0017|Tag 9F03: ;1312|Tag 9F1A: ;1300|Tag 9F26: ;1321|Tag 9F27: ;1303|Tag 9F34: ;1320|Tag 9F36: ;1323|Tag 9F37: ;1305|Tag 9F10: ;1335|TAC: ;1336|TACd: ;1337|TACo: ;1329|Tag 9F0D: ;1330|Tag 9F0E: ;1331|Tag 9F0F: ;1358|Tag 9C: ;

If the first Generate AC action returns an “AAC” cryptogram instead of the expected online “ARQC” cryptogram, the default value for 1380 is based on field 0054 and identified below.

Entry Method (Swiped)

  • Field 54 (90)
  • Field 1380 (SWIPED)

Entry Method (Manual/Key Entry)

  • Field 54 (01)
  • Field 1380 (MANUAL KEYED)

Entry Method (CHIP)

  • Field 54 (05)
  • Field 1380 (CHIP)

Entry Method (Contactless)

  • Field 54 (07)
  • Field 1380 (Contactless)

Entry Method (Fallback to Swipe)

  • Field 54 (80)
  • Field 1380 (CHIP/MAG)

Decoding the ICC Application Preferred Name

EMV Tag 9F12 (API Field 1326), ICC Application Preferred Name, has permitted characters that are non-control as defined in the ISO/IEC 8859 that may need translation depending upon the configuration of your terminal. In order to translate non-standard character sets, the payment application will need to refer to the EMV Tag 9F11.

The following table represents what is in Tag 9F11, the Issuer Code Table Index, a value to indicate the code table according to ISO/IEC 8859 for displaying the Application Preferred Name.

  • Value (‘01’)

    • Refers to: Part 1 of ISO/IEC 8859

  • Value (‘02’)

    • Refers to: Part 2 of ISO/IEC 8859

  • Value (‘03’)

    • Refers to: Part 3 of ISO/IEC 8859

  • Value (‘04’)

    • Refers to: Part 4 of ISO/IEC 8859

  • Value (‘05’)

    • Refers to: Part 5 of ISO/IEC 8859

  • Value (‘06’)

    • Refers to: Part 6 of ISO/IEC 8859

  • Value (‘07’)

    • Refers to: Part 7 of ISO/IEC 8859

  • Value (‘08’)

    • Refers to: Part 8 of ISO/IEC 8859

  • Value (‘09’)

    • Refers to: Part 9 of ISO/IEC 8859

  • Value (‘10’)

    • Refers to: Part 10 of ISO/IEC 8859

EMV Data Retention by the POS

Any EMV transaction data obtained after Fusebox returns the response data to the payment application, including any data available after the 2nd Generate AC and Risk Analysis processing, will not be in Fusebox. This information should be retained by the POS system for receipts, subsequent transactions in the life cycle, chargebacks, cardholder issuer diagnosing, etc.

Check the EMV API Fields for identification of what EMV fields should be retained.