# Printing Receipts 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](https://www.ftc.gov/tips-advice/business-center/guidance/slip-showing-federal-law-requires-all-businesses-truncate) # Presenting Receipts 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. ## Consumer Receipts 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. ## Merchant Receipts 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. ## EMV Receipts 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](https://www.ftc.gov/tips-advice/business-center/guidance/slip-showing-federal-law-requires-all-businesses-truncate) 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. | # Receipt Format Options This API provides receipt data in one of two formats. ## Formatted Receipts 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 ``` ## Raw Tags 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: 1. ApplicationIdentifier 2. TerminalVerificationResults 3. IssuerApplicationData 4. TransactionStatusIndicator 5. 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 ``` ### Dynamic Currency Conversion (DCC) Receipts: 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 ``` # Supporting Built-In Receipt Printing Capability on Devices If you support devices with built-in receipt printers, you can print receipts by sending a [Print Receipt](/apis/payments-platform-rest/openapi/devices/devicesprint) request along with the text to be printed in the `receipt.printValue` field following a transaction that requires a printed receipt. ## Commerce Engine Controlled Pax Devices Printing 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. ## UTG Controlled Ingenico Device Printing | Start | Tag End | Tag Description | | --- | --- | --- | | <$Cut> | | Advances the receipt a few lines so that it can be torn off. | | <$Bold> | | Bolds the text between two tabs. | | <$Reverse> | | Prints white text on a black background. | | <$DoubleChar> | | Prints double-wide characters. | | <$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 ``` ### Printing Bar Codes 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> | | 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 ``` 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.