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
Consumer Relationship Management Tokens (CRM Tokens)
To improve customer experience through loyalty initiatives or to prevent fraud, our APIs return CRM tokens whenever available for every card data request. These tokens will help you manage your customer relationships.
These tokens also increase the security level of your infrastructure by not storing sensitive cardholder data such as the PAN (Primary Account Number). This approach reduces your PCI DSS compliancy level.
The CRM 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 will return a unique CRM Token)
- Generated by Worldline as a “mask” for the card number, keeping the format of a card number (e.g. 4974034362433538108 or 497403K4J3538108)
- Randomly generated within Worldline’s hosted infrastructure
- Displayed through your CRM toolsgiving you the ability to get all transaction reports based on the CRM token.
- If the CRM Token could not be generated, the transaction will still complete but no token will be returned.
The CRM (Generated) Token is returned as:
"externalTokenLinked":
{
"GeneratedToken": "string"
}
Offline tokens
Contact us to activate this option.
Offline Tokens are a great 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. Possible use cases:
- Click & Collect: An Offline Token is computed and returned during the Click operation performed online. For the Collect phase, the Offline Token is computed in the in-store terminal and compared to the pre-registered value, to authenticate the consumer as being the originator of the purchase.
- User authentication: The customer can benefit from a service (rental, parking, etc.) by authenticating him/herself at the entrance or exit of the premises in an 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 & instore transaction will return a unique Offline Token).
- Hexa 64 digits computed by Worldline from the PAN & a key, not keeping the format of a card number (e.g. 4A76C5F8...).
- Randomly generated within Worldline’s hosted infrastructure.
- Can be computed when the in-store terminal is offline.
- The Offline Token is displayed through your CRM tools allowing you to get all transactions reports based on the Offline token.
- The Offline Token is an option that must be enabled during account setup.
- If the Offline Token could not be generated, the transaction will still complete, but no token will be returned.
The Offline (Computed) Token is returned as:
"externalTokenLinked":
{
"ComputedToken": "string"
},