menu

Payment API

What's on this page

In-person Payments / SoftPOS / Basic Operations / Handling Receipts

Handling receipts

Introduction

An EFT - Electronic Funds Transfer - receipt (Part C in the picture below) is generated by a EFT terminal and has the status of legal evidence and this evidence is to be owned by the cardholder. That means that equipment using EFT terminals must be able to supply the EFT receipt to the cardholder.

During a transaction, the POS will be responsible for printing the following sections of the receipt:

  • Header Lines: The contents of these header lines, for example name, address and city of the shop are generated by the POS;
  • Sales lines. Containing information about the goods that the cardholder wants to purchase, for example product name, quantity, unit price, VAT. This information is only available in the POS;
  • Footer lines. The contents of these footer lines are only available in the POS and may include a paper cut if the printer supports this.

The Payment Terminal is responsible for generating of the text of the EFT lines. The content of the receipt may not be altered by the POS. Even empty lines must be printed. A failing transaction does not generate a cardholder receipt nor EFT Lines.

Supplying a receipt by e-mail

When a receipt is sent by e-mail to the cardholder the following rules must be met:

  • Prior to do a transaction it shall be clear to the cardholder that the receipt is sent by e-mail;
  • If the e-mail address is not yet known, the cardholder is asked for his e-mail address prior to the transaction;
  • When the cardholder does not want to share his e-mail address and still wants a receipt, the receipt is either printed or the process of purchase products or services is cancelled;
  • After the transaction the cardholder receipt is sent to the e-mail address of the cardholder.

Requirements to journal

Journal is information intended for the merchant and contains information of every single transaction. Journal is generated for both successful and failing transaction but only generated when the card is supported by the payment terminal. Journal is supplied as text based (journalReceipt) or XML based (eJournal).

This information (both journalReceipt and eJournal) is provided in the Transaction response which can be retrieved at the /transaction endpoint. It is optional to store because it is also available to merchant in the PSP backoffice where it is stored permanently in administration belonging to the API key. But many merchants want to have this information to be stored in their own systems, for example to be able to create totals based on card brands and/or booking period totals. In case of conflicts this information can be used towards an acquirer. Note: the information stored in the PSP backoffice is leading above the information stored in merchant systems.