Omnichannel
Introduction
Today, customers experience a brand and not a channel within a brand. They shop both online and in-store, and sometimes, this applies to one single purchase.
Imagine the following scenario:
- Your customers pay a deposit for a product in-store which is out of stock
- You send the product to your customers as soon as it is available and request the payment for the remaining amount online
- Later, your customers inform you that the product is unfortunately defective, asking to return the product. After receiving the returned product, you refund the product online
These examples show how these cross-linking of online/in-store activities prove to be a tremendous challenge for merchants: you need to keep track of all these steps to ensure a correct order system and a satisfactory customer experience.
Our Omnichannel solution will ease your implementation by
- Providing a seamless customer journey
- Giving you a single and unified view of your customers' interactions
Omnichannel groups all operations under one single order, in one chain of action – regardless of whether they happen in-store or online!
Contact your sales representative to request the activation of this feature.
Implement Omnichannel
Omnichannel allows the following maintenance operations:
- When processing transactions via Omnichannel, the
payment.Id
format is a 19-digits identifier. This format is unique for all channels (online and instore). - If the initial transaction is in-store, you can process all maintenance operations described below for the following payment methods:
- This guide explains implementing Omnichannel via our API. You can also perform these maintenance operations manually via the ePortal.
- All JSONs feature the bare minimum of mandatory parameters. Find detailed information about these objects and properties in our API reference.
Process subsequent sales
The first initial transaction marking the beginning of the chain of actions can be either an in-store (via your point-of-sale terminal) or online transaction (via our API).
If you process this initial transaction online, make sure to add
unscheduledCardOnFileRequestor="cardholderInitiated"
unscheduledCardOnFileSequenceIndicator="first"
to your request. This will ensure you comply to the Credentials-On-File regulation (COF) when processing the subsequent transaction.
To process subsequent transactions, send a request to our dedicated SubsequentPayment endpoint:
{
"subsequentCardPaymentMethodSpecificInput":{
"authorizationMode":"SALE"
},
"order":{
"amountOfMoney":{
"amount":3000,
"currencyCode":"EUR"
}
}
}
Property | Description |
---|---|
{paymentId} | The payment.Id of the first transaction (either instore or online) for which you process a new subsequent payment. Add it as a path parameter to the SubsequentPayment endpoint Url |
subsequentCardPaymentMethodSpecificInput. authorizationMode |
Set to either "FINAL_AUTHORIZATION"/"PRE_AUTHORIZATION"/"SALE" depending on whether you want to process payments in (pre)authorisation/direct sale mode |
order.amountOfMoney amount currencyCode |
amount: The gross amount you want to charge for this order currencyCode: The ISO 4217 currency code for this amount |
Process refunds/payouts
Add the following properties to a standard RefundPayment request:
{
"amountOfMoney":{
"amount":100,
"currencyCode":"EUR"
}
}
Property | Description |
---|---|
{paymentId} | The payment.Id of the first transaction (either instore or online) for which you request a refund. Add it as a path parameter to the RefundPayment endpoint Url. |
order.amountOfMoney amount currencyCode |
amount: The gross amount you want to charge for this order. currencyCode: The ISO 4217 currency code for this amount. |
Sometimes you might want to refund more than the amount of the first initial transaction. We have a dedicated endpoint for these kind of requests.
Add the following properties to a standard CreatePayout request:
{
"amountOfMoney":{
"amount":1000,
"currencyCode":"EUR"
},
"omnichannelPayoutSpecificInput":{
"paymentId":"paymentId.id"
}
}
- Our platform will automatically select the most appropriate mode to refund the transaction. This selection is based on the scheme and the currency of the original transaction.
- Omnichannel supports full/partial/multiple refunds. Make sure not to exceed the original paid amount for multiple refunds.
- If you accidentally process a refund twice, our platform will return the error message "
REFUND_ORDER_LOCKED
" in propertyerrors.id
for the second attempt. This is the way our platform handles "double-refund fraud" for transactions involving multiple channels.
Tokenisation
Tokens enhance the Omnichannel experience for both you and your customers. Omnichannel supports Consumer Relationship Management tokens (CRM tokens) and Offline tokens.
CRM Tokens
CRM tokens allow you to:
- Initiate loyalty programs.
- Enable Fraud prevention measurements.
- Lower your PCI compliancy level as you do not have to store sensitive card data (i.e. the Primary Account Number).
CRM tokens possess several key properties:
- Unique per cardholder (two transactions performed with the same card generate the same token).
- Unique across channels (an online and in-store transaction returns a unique CRM Token).
- We generate it as a “mask” for the card number, keeping the format of a card number (e.g. 4974034362433538108 or 497403K4J3538108).
- We generate it randomly within the hosted infrastructure.
- Your CRM tools display it, allowing you to generate transaction reports based on the offline token.
Our platform returns the token for your payment request in property externalTokenLinked. generatedToken .
- Our platform will return CRM tokens for every card data request whenever available.
- If the CRM token cannot be generated, the transaction still completes, but no token is returned.
Offline tokens
Offline tokens are an excellent way to manage orders when the in-store terminal is offline. Our APIs will return offline tokens for any request involving card details, if available.
To activate this option, contact our support team as this feature is not enabled by default.
You can apply offline tokens in the following scenarios:
- Click & Collect: An offline token is computed and returned during the online "Click" operation. For the "Collect" phase, the Offline Token is computed in the in-store terminal. It is compared to the pre-registered value to authenticate the consumer as the originator of the purchase.
- User Authentication: Customers can benefit from services (rental, parking, etc.) by authenticating themselves at the entrance or exit of the premises in offline mode.
The Offline Token has the following properties:
- Unique per cardholder (two transactions performed with the same card will generate the same token).
- Unique across channels (an online and in-store transaction returns a unique Offline Token).
- We compute a Hexa 64 digits from the PAN and a key. This number does not maintain the format of a card number (e.g., 4A76C5F8...).
- We generate it randomly within the hosted infrastructure. You can compute it when the in-store terminal is offline.
- Your CRM tools display it, allowing you to generate transaction reports based on the offline token.
- You must enable the Offline Token option during account setup.
Our platform returns the token for your payment request in property externalTokenLinked. computedToken.
If the offline token cannot be generated, the transaction still completes. However, you do not receive a token.