It is possible to identify the customers by a (payment) card inserted in the payment terminal at the POI, used in the payment transaction. It is technically possible, because the payment terminal can generate a token of the card number. This token is made using a "hashing algorithm", which is an irreversible mathematical function generating a unique token, from which the real card number cannot be extracted.

This means that storing and transmitting the token through your system does NOT require your system to be PCI-DSS compliant.

The token is transferred to the cashier system/POS as part of the transaction, you can then store this as part of the transaction with the receipt data and use this as userId when sending the receipt data to storebox.com as described below.

To support the token solution for identifying card number, the payment terminals must be equipped with special software and encryption keys from Storebox in corporation with the terminal supplier. The list of supported terminals is expanding, currently integration is possible with:

• Point: Cashier register integrated terminals (Xenta and Yomani)
• Nets Merchant Solutions: Cashier register integrated terminals with either PSAM or Viking software
• PayEx: Please contact Storebox if in doubt if your terminals are ready for integration.

The end user signs up on the storebox.com website or Storebox app. The website is available on https://www.storebox.com and app on the following locations

• Google Play
• Apple App Store

Storebox JSON

The standard receipt format is JSON as defined in the documentation. The format can contain an embedded PDF, but structured data is still required to display the receipt in a uniform format on the Storebox website and app.

ARTS POSLog

ARTS POSLog version 6.0 is supported by the POS API.

To use ARTS POSLog the following content type has to be set when uploading the receipt.

Content-Type: application/x.arts.poslog.v6

As explained in this document, there are different ways of identifying the end user by payment card, phone number, etc.

ARTS POSLog does not support this identification in the actual receipt data, so identification is set through a HTTP header called X-Storebox-userid. The format is <type>=<value> if multiple ids are provided they are separated by “;”. For example

X-Storebox-userid: pan=foobar;msisdn=4511223344

The type and value are explained in the receipt model.

Storebox Download JSON

In some situations the receipt might be available on an external service like Azure Blob Storage or AWS S3.

It is possible for the POS API to fetch the receipt from there and process that receipt.

Instead of uploading a new receipt, a receipt reference is used which has the following format

{
  "provider": "<provider>",
  "contentType": "<content-type>",
  "params": {
    "<key1>": "<value1>",
    "<key2>": "<value2>"
  }
}

provider is the hosting provider. Currently only Azure Blob Storage is supported. contentType is the content type of the stored receipt, for example if it is in ARTS POSLog. paramsare specific for provider.

To use the reference format the following Content-Type has to be set when calling receipt upload.

Content-Type: application/vnd.storebox.receipt.download+json

Azure example

{
  "provider": "azure",
  "contentType": "application/x.arts.poslog.v6",
  "params": {
    "name": "20170618_213244363-110805-25926",
    "uri": "https://example.blob.core.windows.net/example?sv=2015-04-05&sr=c&sig=validsignature&st=2017-06-07T09%3A24%3A30Z&se=2027-06-07T09%3A29%3A30Z&sp=rw"
  }
}

In the production environment, only production tokens are created. This means that test terminals cannot be used.

The same is true for the test system where only test tokens are generated, so only test terminals work.

When using the test system, the receipts will be available on test.storebox.com. This website works as the production website, so users can be created, and payment card added.

The POS API will ignore duplicate receipts. A receipt is defined as a duplicate if the checksum is the same as an existing receipt. Changing receipt id will not make the receipt different, however added a newline will.

This allows interation to message queues that cannot guarantee single delivery.

Receipt operations

Documents provides merchants the ability to upload and attach documents, i.e. user guides, Quick start tutorials, warrenty documents and many more, to receipts.

The user operations in the POS API serve two purposes

• Check if an user is Storebox user
• Check if an user has indicated that they do not want printed receipts (green profile)

The ECR can use the appropriate endpoint to check the identity token and make the choice of what to do.

It is optional to do a lookup of Storebox users before sending the receipts. The Storebox system will discard the receipts that are not matched. It is the preferred method to send all the receipts.

A Storebox user can configure in the Storebox app/website that they prefer not a get a printed receipt.

This is configuration returned in success user lookups

{
    "prefersNoPrintedReceipts": true
}

When a card token is used as user lookup, multiple users may have that card added to their profile. In this case prefersNoPrintedReceipts will return false if any of the users have disabled green profile

Before sending receipts to the POS API, the sending merchant must be registered. These endpoints allow for creating a merchant and associating a logo, that will be shown with the receipt when displayed in app or web.

Text formatting attributes

Each text line can be formatted using a predefined list of attributes. The text line must be prefixed with the attributes and the attributes must be contained within ‘$’ characters. For example, to format a line with bold text use: “$b$ this line will be in bold text”.

More than one attribute can be listed on the same line if placed inside the same pair of ‘$’, but the attributes must be separated using a semicolon ‘;’. For example, to format a line in bold and italic with center aligment use: “$b;i;center$ this line will be in bold italic aligned center”.

Supported attributes

Graphical attributes

Each line can display a predefined list of graphical elements. Each graphical element must be contained within ‘$’ characters and parameters for each element separated by colon ‘:’. For example, to add a centered image use: “$image:fotex:50:center$”. One graphical element is supported for each line.

Supported attributes