Handover
There are many ways to handover a digital receipt to shoppers using the warrify API. Some of them require additional identification at the point of sale, such as a digital wallet pass or temporary ID. Others function completely seamlessly, matching sales to shoppers behind the scenes. This can happen, among other things, via payment information or customer ids.
To enable flexible ways to deliver receipts to shoppers it is required that ALL sales are sent to the warrify API (Not only those with a customerId
or a com.warrify.warrify-card
extension).
Below are some of the ways to deliver digital receipts to shoppers.
Loyalty App
Using the checkout API one can offer a purchase history for registered shoppers.
When a shopper presents their loyalty card at checkout send the customer id in the $.customer.customerId
attribute.
The purchases of a given customer can then be retrieved via a call to listSales
by specifying a filter such as filter[query]=customer.customerId==056343
.
Printed QR-Code
One of the simplest ways is to add a scannable QR code to the printed receipt that will take shoppers to the digital receipt.
When printing such a QR code make sure to use the URL in the $.data.links.permalink
field of the createSale
response.
Using a customer facing display (Dynamic QR-Code)
When a customer facing display or sign-pad is present a unique QR Code that takes a customer straight to their digital receipt can be shown after checkout.
-
Gather line item information just as you would do normally.
-
Then process the payment as usual. This can be anything from cash, credit card to coupons.
-
After the payment send the line item, payment and general information in the specified format to the /sales/ endpoint.
-
In case of any error you SHOULD fallback to the physical printer to fullfil any legal obligations.
-
If everything worked out (HTTP Status Code 201 returned) the response contains the created sale. You SHOULD NOT issue a separate GET request to fetch the sale you just created. All data needed is in the response of the POST request. Inside the
/data/links/
field you will find 3 linkscopy
,original
andpermalink
. Depending on whether a receipt was also printed you MUST use theoriginal
orcopy
link respectively to make it accessible to the customer. When a QR-Code is also printed on the receipt you MUST use thepermalink
link in the printed QR-Code.Some options include:
-
Display a QR-Code that contains the link on a second screen for the customer to scan.
-
Load the Link into a NFC tag for the user to scan.
-
Print the Link onto the print out of the receipt.
-
If you have an existing loyalty program which includes a mobile App, you MAY send the link (together with the customer id) to your backend which in turn sends the customer a push notification containing the link which the customer then can view in their browser or a webview inside your loyalty App. Though remember that in this case you are responsible for delivering the notification (possibly in a timely manner) to the customer.
-
Without a customer facing display (Temporary Warrify Card)
If such a display is not available you can choose the second option and scan a code that is shown to you by the customer, similar to a loyalty card.
-
Gather line item information just as you would do normally.
-
During the checkout scan the code presented to you by the customer from their smartphone.
-
Then process the payment as usual. This can be anything from cash, credit card to coupons.
-
After the payment send the data inside the
/data/extensions
field as an extension of typecom.warrify.warrify-card
alongside the line item, payment and general information in the specified format to the /sales/ endpoint. -
In case of any error you SHOULD fallback to the physical printer to fullfil any legal obligations.
-
If everything worked out (HTTP Status Code 201 returned) the response contains the created receipt. No further steps are required HOWEVER one can include a link to the receipt on the printout of the receipt. For this you MUST use the
permalink
link inside the/data/links
field.
Supported Codes
As of today we support the following types of codes:
QR
The content of the QR code will be one of:
URL Encoded String
An URL encoded
string (e.g. p=wrfy&a=foo&b=Hello%20World&a=bar
). This string will ALWAYS start with
p=wrfy
to uniquely identify a warrify QR code. Other parameters in the string will be
arbitrary key-value pairs. You MUST NOT make any assumptions on the included data.
The string will NOT include a protocol or hostname but simply uses the URL encoding
for query parameters as a compact and safe transport encoding.
The contents of this URL encoded string MAY be decoded into a JSON
object, where multiple occurrences of the same key MUST result in an array. The prefix p=wrfy
SHOULD
be omitted.
For example p=wrfy&a=foo&b=Hello%20World&a=bar
results in
{
"a": ["foo", "bar"],
"b": "Hello World"
}
The contents of the encoded string MUST be sent in the attributes/content
field of the com.warrify.warrify-card
extension.
Reserved words
The following parameters have a specific meaning.
key (case insensitive) | type | description | default |
---|---|---|---|
prt | enum: 0 , 1 | Whether to print the receipt or not. If 0 DO NOT print. | 1 (meaning print by default) |
URI
An URI with the scheme wrfy
(e.g. wrfy:?a=foo&b=Hello%20World&a=bar
).
Since this string will ALWAYS start with wrfy:
it uniquely identifies a warrify QR code.
Other parameters in the string will be arbitrary key-value pairs in the query section of the URI.
You MUST NOT make any assumptions on the included data.
The contents of this URI query MAY be decoded into a JSON object, where multiple occurrences of the same key MUST result in an array.
For example wrfy:?a=foo&b=Hello%20World&a=bar
results in
{
"a": ["foo", "bar"],
"b": "Hello World"
}
The contents of the encoded string MUST be sent in the attributes/content
field of the com.warrify.warrify-card
extension.
GS1-128 (formerly UCC/EAN128)
As an alternative to the 2 dimensional QR code, which might not be supported by all barcode readers we allow the generation of GS1-128 codes. The GS1-128 uses Code128 as the representation. It works by using Application Identifiers to identify the intend of the data. The list of Application Identifiers in Section 3 of the GS1 General Specification lists codes 91 to 99 for internal use.
This means that an application identifier specific for each retailer needs to be designated
for the warrify digital receipt. This should ideally be done as a configuration
parameter, so that each retailer can configure it to avoid collisions. The warrify GS1-128
will have the following format, where [FNC1]
denotes the "Function Code 1" of the GS1 standard
and [AI]
the selected Application Identifier. The data following the Application Identifier
consists of an alphanumeric string ´[0–9, A–Z, a–z]´. Depending on the configuration
this can be restricted to the character sets supported by the different
Code 128 Subtypes.
[FNC1] [AI] 12345678901234567890
The data of the code (the part after the application identifier [AI]
) has to be
transmitted in the attributes/content
field of the com.warrify.warrify-card
extension.