Skip to content

Create Receipt

When considering a receipt, the origin is the key: what the receipt belongs to?

The answer always is: a Sale Response. A receipt can only be generated from an actual existing sale or payment, so make sure you have the sale response at hand (either because you just completed one, or because you queried it from History).

Receipts are very important, legal and management wise, but there is no reason to worry: our ePOS SDK removes all the hassle. In the sample codes below you will find how to get the receipt for a whole sale (or for a specific payment within the sale; the functions is used equally for both cases). But there is some level of customisation we offer you that maybe be of your interest.

Customisation (iOS)

Think about the nature of the receipt. Is it for the clerk/seller, or is it for the end customer/cardholder? There are small but important information (such as non critical card info, for example) that are required in one or the other case. As a general rule for you, the way to proceed is easy:

  • Are you showing the receipt in the screen of your app, or is the clerk printing the receipt for himself/herself? Then it is a non-cardholder receipt.
  • Are you printing the receipt for the end customer, or sending the receipt to the end customer? Then it is a cardholder receipt.

With the nature of the receiver clear, you can adapt the content as well. For example: how long do you want your receipt?

If you are printing a single payment, the length is gonna be expected, but if your sale consist of several payments, including returns of items, the printing process will give you what looks like several receipts, all concatenated in chronological order. If you want to avoid this, simply specify that your receipt must NOT show returns.

Other important content settings you may need to change are the format and the printing resolution of the receipt. The receipt can be returned to you as image, a pdf, html, or printer compatible formats for our supported devices - it is up to you. The default resolution, however, is recommended to leave it as it is presented our demo examples.

Additionaly, you can set the language and locale of the receipt you want to print. See the public headers for more info. Supported languages include English, German, French, Spanish, Simplified Chinese, Polish, Czech, Italian, Dutch, Estonian, Lithuanian, Latvian, and more to come.

Note

Additional customisations of receipt (ie Header and Footer logos) can be dynamically modified in your merchant setup in our backend. Please ask support about Merchant Metadata and Configuration.

Customisation (Android)

Android receipt is represented by data class PrintableReceipt, which contains all necessary information and is fully customizable. Android demo application shows how to fill up PrintableReceipt base on Sale object. Filled PrintableReceipt can be used to print or show receipt.

EposSDK provides ReceiptUtil to generate html version of receipt, which can be shown in android WebView.

The Sample Code

Universal Windows Platform SDK coming soon