Shift4 provides the data necessary for your interface to build receipts for both EMV and non-EMV transactions. Shift4's receipt data is based on the processors’ specifications for both format and content.
Federal law requires all businesses to truncate credit card information on receipts. Make sure your receipt does not display the card’s expiration date and only displays the last four digits of the card number. See the example below:
ACCTXXXXXXXXXXXX1234
For more information, see: ftc.gov
Your interface will be required to properly handle generating receipts for both the consumer and merchant (or in card-not-present transactions, for only the consumer). The presentation method (e.g., digital or on paper) is based on the processor’s requirements, merchant’s policies, and/or consumer’s preference. Detailed information about the requirements for consumer receipts and merchant receipts is provided below.
How and when in the payment flow a receipt is presented to the consumer varies based on the merchant’s industry and processing flow. Below are some examples of specific requirements:
- Lodging merchants are required to present receipts to consumers at two points: when the billing terms are printed on the folio at check in and when the final invoice is printed on the folio at check out.
- For card-not-present transactions, such as e-commerce and MO/TO (mail order/telephone order), an invoice that contains the customer-receipt text should be provided to the consumer. Depending on the merchant’s operational practices, this invoice may be provided via email, a statement on an online portal, or printed and shipped with purchased goods.
- Refund receipts should never include a tip line.
Your interface must provide copies of receipts for the merchant’s record and use in chargeback defense. Merchant-receipt copies can be generated and stored electronically when a signature is digitally captured. If a signature is not digitally captured for a card-present transaction, a paper record of the consumer’s signature is required.
Federal law requires all businesses to truncate credit card information on receipts. Make sure your receipt does not display the card’s expiration date and only displays the last four digits of the card number. See the example below:
ACCTXXXXXXXXXXXX1234
For more information, see: ftc.gov
The processors require merchants processing EMV payments to print receipts. The scenarios in which a receipt must be printed varies depending on the country:
Country | Scenarios requiring receipts |
---|---|
US | approvals (sale or authorization), declines |
Canada | approvals (sale or authorization), declines, referrals, errors, refunds, and voids of previously approved transactions. |
This API provides receipt data in one of two formats.
When a formatted receipt is requested by the interface, Shift4 will not return the raw tags in the receipt array. Instead, the returned receipt array will have just two items, merchantText and customerText, each of which will contain pre-formatted receipt text which is compliant with the processor's requirements. Using formatted receipts can greatly speed up development time at the cost of flexibility. In order to receive a formatted receipt in the response, your interface will need to send the receiptColumns
field.
Below is a sample of a formatted receipt for a non-EMV transaction.
CREDIT CARD
SALE
06/21/2018 08:29:04
CARD TYPE VISA
ENTRY METHOD KEYED
CARD # XXXXXXXXXXXX2257
INVOICE 6263175163
CLERK 62626
APPROVED OK959Z
AMOUNT USD $12.35
I AGREE TO PAY ABOVE TOTAL AMOUNT
ACCORDING TO CARD ISSUER AGREEMENT OR
MERCHANT AGREEMENT IF CREDIT VOUCHER
Jane Doe
CARDHOLDER COPY
When a formatted receipt is not requested by the interface, the receipt elements are returned as an array of Receipt objects. An interface that builds receipts based on this raw information has great flexibility in the receipt format, but choosing this route may significantly increase development time. Each Receipt object consists of up to three properties:
Property | Description |
---|---|
key | The identifier the interface vendor can use to programatically determine where to print a specific value. |
printName | The label that relates to the printValue field. When present in the response, this must be printed to the left of the printValue . |
printValue | The value that relates to the printName field. This must be printed to the right of the printName . |
When printing EMV receipts, the following elements must be grouped together and printed in the following order:
- ApplicationIdentifier
- TerminalVerificationResults
- IssuerApplicationData
- TransactionStatusIndicator
- AuthorizationResponseCode
The exact list of tags that will be returned in production will vary. Generally speaking, all other tags returned in the receipt array should be printed on the receipt. However, each processor has its own set of rules, so ISVs building their own receipts are advised to check the requirements for each of the processor(s) they wish to be compliant with.
Key | Print Name Example | Print Value Example | Notes |
---|---|---|---|
TransactionType | PURCHASE | ||
TransactionResponse | Response | APPROVED | |
CardholderVerificationMethod | CVM | PIN VERIFIED | |
ApplicationIdentifier | AID | A0000000031010 | |
TerminalVerificationResults | TVR | 0000008000 | |
IssuerApplicationData | IAD | 06010A03A40002 | |
TransactionStatusIndicator | TSI | E800 | |
AuthorizationResponseCode | ARC | 00 | |
TransactionCurrencyCode | USD$ | Must be printed on the total amount line. | |
ApplicationLabel | CREDITO DE VISA | ||
MaskedPAN | XXXXXXXXXXXX1119 | ||
CardEntryMode | ENTRY METHOD | CHIP | |
PANSequenceNumber | 5F34 | 01 | |
ApplicationInterchangeProfile | 82 | 5400 | |
TransactionDate | 9A | 180702 | |
TransactionTime | 9F21 | 115528 | |
AmountAuthorized | 9F02 | 000000040000 | |
OtherAmount | 9F03 | 000000002000 | |
ApplicationUsageControl | 9F07 | 1234 | |
IssuerActionCodeDefault | 9F0D | 1234567890 | |
IssuerActionCodeDenial | 9F0E | 1234567890 | |
IssuerActionCodeOnline | 9F0F | 1234567890 | |
TerminalCountryCode | 9F1A | 0840 | |
ApplicationCryptogram | 9F26 | 75D0FE1CFCA55605 | |
CryptogramInformationData | 9F27 | 00 | |
CVMResults | 9F34 | 1E0300 | |
ApplicationTransactionData | 9F36 | 0002 | |
UnpredictableNumber | 9F37 | B8FD22D7 | |
AccountType | ACCT | Savings | |
TerminalActionCodeDefault | TAC Default | DC4000A800 | Shift4 will not return this, but it needs to be included on the receipt. |
TerminalActionCodeDenial | TAC Denial | 0010000000 | Shift4 will not return this, but it needs to be included on the receipt. |
TerminalActionCodeOnline | TAC Online | DC4004F800 | Shift4 will not return this, but it needs to be included on the receipt. |
TransactionCurrencyCode | 840 | ||
SignatureRequired | N | This will return Y or N in the Print Value. The value itself should not be printed but can be used to determine if a signature should be requested on the receipt | |
TerminalID | TID | 75495799 | |
dccExchangeRate | EXCHANGE RATE 1 GBP = 1.3383 USD | ||
dccMarkup | INCLUDES 1.5025% OVER WHOLESALE RATE | ||
dccTranCurrency | Trans Currency | USD | |
dccTranAmount | Trans Amount | 148.55 | |
dccDisclaimer | I HAVE BEEN OFFERED A CHOICE OF PAYMENT CURRENCIES INCLUDING USD | ||
dccOfferedBy | THIS CURRENCY CONVERSION SERVICE IS OFFERED BY THE MERCHANT | ||
SurchargeAmount | Surcharge | 3.00 | |
SurchargeDisclaimer | A 2.5% surcharge has been added to cover the cost of accepting credit cards. This fee is not a service charge or gratuity. |
Below is a sample of a receipt for an approved EMV transaction that might be built from the raw tags.
Sample Store
123 Great Road
Las Vegas, NV 89144
702-555-5555
06/21/2018 09:21:14
MID: XXXXXXXXXXXX9137
TID: XXX2946
Purchase
Mastercard Credit ************6405
Entry Mode: CHIP
CVM: PIN VERIFIED
Invoice 192029
Clerk 16
Total Amount USD$ 12.95
Response: APPROVED
Auth Code: 217983
AID: A0000000041010
TVR: 0820000000
IAD: 092B302A9104
TSI: C800
ARC: 00
CUSTOMER COPY
When DCC is enabled on a device and the cardholder chooses to pay in their currency instead of the merchant currency, the dcc.conversionIndicator
will return 1
in the transaction response indicating the cardholder opted into DCC. The following DCC elements must be printed on the receipt if the cardholder opted into DCC:
- dccExchangeRate
- dccMarkup
- dccTranCurrency
- dccTranAmount
- dccDisclaimer
- dccOfferedBy
Below is a sample receipt for an approved contactless EMV transaction with DCC:
Sample Store
123 Great Road
Las Vegas, NV 89144
702-555-5555
06/27/2025 12:54:38
MID: XXXXXXXXXXXX9137
TID: XXX2946
Purchase
Mastercard Credit ************6405
Entry Mode: CONTACTLESS
CVM: PIN VERIFIED
Invoice 192029
Clerk 16
Total Amount GBP£ 111.00
EXCHANGE RATE 1 GBP = 1.3383 USD
INCLUDES 1.5025% OVER WHOLESALE RATE
TRANS CURRENCY USD
TRANS AMOUNT 148.55
I HAVE BEEN OFFERED A CHOICE OF
PAYMENT CURRENCIES INCLUDING USD
THIS CURRENCY CONVERSION SERVICE IS
OFFERED BY THE MERCHANT
Response: APPROVED
Auth Code: 217983
AID: A0000000041010
TVR: 0820000000
IAD: 092B302A9104
TSI: C800
ARC: 00
CUSTOMER COPY
If you support devices with built-in receipt printers, you can print receipts by sending a Print Receipt request along with the text to be printed in the receipt.printValue
field following a transaction that requires a printed receipt.
The Pax A930 and A800 device printers support a maximum of length of 29 characters per line. When formatting each line in the receipt.printValue
field, you must ensure that no line is longer than 29 characters, otherwise Commerce Engine will return an error.
The functionality for printing with various tags (<$Bold>
, <$Reverse>
, etc.) and the ability to print bar codes is not currently supported via Commerce Engine controlled Pax devices.
Start | Tag End | Tag Description |
---|---|---|
<$Cut> | Advances the receipt a few lines so that it can be torn off. | |
<$Bold> | <Bold$> | Bolds the text between two tabs. |
<$Reverse> | <Reverse$> | Prints white text on a black background. |
<$DoubleChar> | <DoubleChar$> | Prints double-wide characters. |
<$BigChar> | <BigChar$> | Prints text in a very large font. |
As an example of using these tags to change how the text may be displayed, if you want to print “Groceries” in bold, it would be sent as:
<$Bold>Groceries<Bold$>
To print scannable bar codes on receipt, send the desired bar code tags from the list below with the receipt text in the receipt.printValue
field.
Start | Tag End | Tag Description |
---|---|---|
<$BarCode> | <BarCode$> | Prints a bar code from the data between thetags. |
<$BarCode39> | Switches to Code 39 format for bar code printing (default). | |
<$BarCode39> | Switches to Code 39 format for bar code printing (default). | |
<$BarCode128> | Switches to Code 128 format for bar code printing. | |
<$BarCode25> | Switches to Code 25 format for bar code printing. | |
<$BarCodeEAN8> | Switches to EAN-8 format (7 digits)for bar code printing. | |
<$BarCodeEAN13> | Switches to EAN-13 format (12 digits)for bar code printing. | |
<$BarCodeHeightNNN> | Configures the height of the bar codein pixels where NNN is the 3-digit value for the pixel width. | |
<$BarCodeWidthNNN> | Configures the width of the bar codein pixels where NNN is the 3-digit value for the pixel width. | |
<$BarCodeHorizontal> | Switches the bar code to a horizontallayout. | |
<$BarCodeVertical> | Switches the bar code to a verticallayout. | |
<$BarCodeAlignCenter> | Prints the bar code in the middle ofthe receipt. | |
<$BarCodeAlignLeft> | Prints the bar code on the left sideof the receipt. | |
<$BarCodeAlignRight> | Prints the bar code on the right sideof the receipt. |
These tags can be chained. For example, if you want to left align a vertical bar code of “123456” using format 39, then you would send the following:
<$BarCode39><$BarCodeVertical><$BarCodeAlignLeft><$BarCode>123456<BarCode$>
Some devices apply the bar code settings that were last used. Therefore, Shift4 recommends sending the format, including the height, width, and layout configuration (i.e., horizontal or vertical), and alignment for each bar code in the receipt.printValue
field to ensure that it is printed as desired.