Point-of-sale icon

Show a virtual receipt on the terminal

Show a virtual receipt on the display of the payment terminal.

Before the payment transaction starts, you can use the payment terminal to show the shopper an overview of their purchase. You can also add a QR code to this virtual receipt.
This functionality is available for the following terminal models:

  • AMS1
  • e280
  • M400
  • P400 Plus
  • S1E
  • S1F2
  • V400c Plus
  • V400m

A request to show a virtual receipt doesn't time out. The terminal continues to show the receipt until you send another request. For example, a payment request, or a request to show the standby screen.

Without QR code

The next examples show what virtual receipts look like on landscape (wide) and portrait (narrow) terminal displays. The receipt lines are scrollable.

With QR code

It is also possible to add a QR code. A terminal with a landscape display shows the QR code next to the receipt lines.

A terminal with a portrait display shows two screens. First a screen with the QR code and a button to proceed, and then a screen with the receipt lines.

 

Receipt XML file

To show a virtual receipt on the terminal display, you need to gather all content in an XML file, convert this file to a Base64 string, and pass that string in a display request.

The XML file can contain:

  • <screen name>: the XSLT to use. This determines whether a QR code is added to the virtual receipt.
  • <qrcodeblock>: QR code with a header and footer. When used with a <screen name> that doesn't show a QR code, the <qrcodeblock> is ignored.
  • <list-header>: the header line of the virtual receipt.
  • <lines>: contains line items that represent the goods that the shopper is purchasing. Each line item can have a count, description, and amount.
  • <subtotal>: amount due before discounts and taxes.
  • <tax>: total discounts, amount and type of taxes, total tax amount.
  • <total>: final amount due.

Use the following example XML file to populate an XML input file with line items and total amounts from your POS app, making sure you specify a <screen name> that is compatible with the terminal and the result you want to achieve:

Effect <screen name> Terminal model

Receipt with QR code

virtual-receipt-with-qr-code.xslt

All that support virtual receipts

Receipt without QR code

virtual-receipt.xslt

AMS1, e280, P400 Plus, S1E, S1F2, V400c Plus, V400m

virtual_receipt02.xslt

M400

Receipt without QR code,
receipt header not 'sticky'

virtual_receipt01.xslt

M400

Receipt without QR code,
receipt header not 'sticky',
receipt footer 'sticky',
auto-scroll to the bottom

virtual-receipt01.xslt

AMS1, S1E, S1F2, V400M, P400

virtual_receipt03.xslt

M400

On the terminal screen, the currency symbol only shows for the total amount.

Make a display request for a virtual receipt

  1. Create the virtual receipt:

    1. Based on our example XML file, populate an XML file with line items and total amounts from your POS app. Make sure you use the correct screen name:

      • <screen name="virtual-receipt.xslt">: shows a receipt without QR code where the receipt has a 'sticky' header which remains visible when scrolling down the receipt lines. For use on portrait terminals: AMS1, e280, P400 Plus, S1E, S1F2, V400c Plus, and V400m.
      • <screen name="virtual-receipt-with-qr-code.xslt">: shows a receipt with a QR code. For use on any terminal model that supports virtual receipts.
      • <screen name="virtual_receipt01.xslt">: shows a receipt without QR code. For use on the M400.
      • <screen name="virtual_receipt02.xslt">: shows a receipt without QR code but with a 'sticky' header. For use on the M400.
      • <screen name="virtual-receipt01.xslt">: shows a receipt without QR code, a 'sticky' footer, and auto-scroll to the bottom. For use on the AMS1, S1E, S1F2, V400M and P400.
      • <screen name="virtual_receipt03.xslt">: shows a receipt without QR code, a 'sticky' footer, and auto-scroll to the bottom. For use on the M400.

    2. Convert the XML content to a Base64 string.

  2. Make a POST request to a Terminal API endpoint, specifying:

    • MessageHeader: the standard SaleToPOIRequest.MessageHeader object. Specify:

      Parameter Required Description
      ProtocolVersion -white_check_mark- 3.0
      MessageClass -white_check_mark- Device
      MessageCategory -white_check_mark- Display
      MessageType -white_check_mark- Request
      ServiceID -white_check_mark- Your unique ID for this request, consisting of 1-10 alphanumeric characters. Must be unique within the last 48 hours for the terminal (POIID) being used.
      SaleID -white_check_mark- Your unique ID for the POS system component to send this request from.
      POIID -white_check_mark- The unique ID of the terminal to send this request to. Format: [device model]-[serial number].
    • DisplayRequest.DisplayOutput : an array containing a single array item with:

      Parameter Description
      Device CustomerDisplay
      InfoQualify Display
      OutputContent.OutputFormat XHTML
      OutputContent.OutputXHTML The Base64 string containing the XML content.

    If the request is successful, you receive a display response with:

    • OutputResult.Response.Result: Success

    If the request is not successful, you receive a display response with:

    • OutputResult.Response.Result: Failure.
    • AdditionalResponse and ErrorCondition: more information about why the request failed.

    See XML validation for information about how errors in the XML content are reported.
    The next example shows the response after sending the display request to an incompatible terminal:

XML validation

When we receive your display request for a virtual receipt, we check whether we can parse the XML content. We can also check whether the XML content matches the XML Schema Definition (XSD). We only do this XSD check if it is enabled for your account.

  • Parsing
    We always check whether we can parse the XML content of your request.

    For example, if the XML contains a syntax error like a missing caret >, we can't parse the XML. We'll send a failure response with XHTML data could not be parsed.

  • XSD
    If we can parse the XML content and XSD checking is enabled, we validate the XML against the XSD.

    To use this validation, ask our Support Team to enable the virtual receipt XSD check.

    For example, if you add an element that is not in the XSD or if you omit a required element, the XML doesn't match the XSD. We'll send a failure response with XSD validation failed.

    The details of any XSD errors are in the terminal log.

See also