Receipt guidelines
NOTE2: This article covers receipt printing guidelines and best practices, for technical implementation refer to this article
The card networks regularly update their receipt requirements and we push these changes to our terminals through new software updates. It's important that you follow the guidelines below so that you can automatically take part of these changes without having to issue a new release of your application every time. Receipt printing is verified in the certification so make sure you read the following guidelines.
What do I print on the receipt?
The source of the receipt shall exclusively use the "receipt" object. This object is built directly on the terminals internal receipt engine and will be automatically updated with the terminal software version. Constructing a custom receipt by using the separate data elements in the transaction response is not allowed as this requires a lot of complicated logic and upkeep from you as an ECR supplier. These recommendations are meant to be as future-proof as possible.
When do I print a receipt?
A transaction receipt should always be offered to the cardholder when a payment attempt is performed regardless if its approved or declined, if they do not wish to receive a receipt you can omit printing it.
A transaction receipt should be offered in one of three ways:
- Printed directly from the terminals printer (if supported by terminal model)
- Printed separately from an external printer (fig A)
- Printed embedded into the ECR receipt (fig B)
 |  |
| Figure A | Figure B |
Which receipt do I print?
Depending on the type of transaction either customer, merchants or both copies are expected to be printed. To remain compliant simply follow the "shouldPrint" constraint in the "receipt" object. If it returns true, print the associated the receipt.
"customer": {
"shouldPrint": true,
"escpos": "string",
"plain": "string",
"embeddedPlain": {
"header": "string",
"content": "string",
"footer": "string"
}
},
"merchant": {
"shouldPrint": false,
"escpos": "string",
"plain": "string",
"embeddedPlain": {
"header": "string",
"content": "string",
"footer": "string"
}
}
The receipt is available in three formats, you only need to use one:
Plain
This is a plaintext receipt with tab characters ("\t") and new lines ("\n"). If you are printing a separate terminal receipt you should be able to send this string directly to a printer to get a result very close to fig. A
ESC/POS
If you are embedding the terminal receipt into your ECR receipt (fig. B) you can use this format to grab the content since your receipt probably already has a header/footer. Details on the format here and a step by step guide here
Word wrapping
While the majority of the receipt can be printed as-is there are some long strings that do not have built-in linebreaks to accommodate different receipt widths, for example DCC disclaimer is one of them, see example text here, similar also happens on Refunds. It is recommended to enable some form of word wrapping to fit the entire text in a compliant manner. When inserting linebreaks they should be inserted on the blank space closest to the row character limit to avoid splitting a word in half. This applies to formats Plain and ESCPOS.
Embedded plain
A new receipt type as of version 2.2 which brings some QoL thanks to integrator feedback!
- This receipt comes with sections so that you can avoid printing a header twice if you intend to embed the receipt into your ECR copy! If you are printing this receipt standalone or your receipt does not contain merchant information then you are still required to print the header section.
- Variable width, you can now set "receiptWidth" (between 30-128 characters, default value 34) in your requests and the terminal will shuffle the receipt spacing according to your specified width, this assumes you are using a monospaced font or your spacing will not be correct. This also takes care of word wrapping problems in long strings.
- This is the recommended default receipt type to use, it will most likely fit your use case!