Integration principles
Voyado must never be critical to the purchase process in checkout, nor to any other business critical contact transaction. A contact should always be able to perform their entire purchase in the POS and e-com, regardless of problems like the client's broadband being down, or firewalls not working, or the Voyado Engage API not responding.
Important
Your systems should continue to operate even if communication to Voyado is down.
A customer should therefore prepare for performance issues, or even the case where communication to Voyado, for whatever reason, is not available. There are several levels of preparation a customer can consider, according to their needs, budget, and ambitions. This can be seen as a kind of insurance. The more a customer invests, in terms of time, planning and resources, the fewer problems and data loss they risk in case of failure.
Cases 2, 3 and 4 below require purchases to be imported to Engage either via XML or API with buffer or temp-DB for potential downtime.
With an intelligent buffer for purchases WITH contact data, it is possible for the integration part to decide whether the contact registered should be pushed as a new contact or only tag the transaction to an existing contact when the connection is back up.
In this case no fail-safe for contact-handling exists. However, the purchase process must always proceed.
Here are a few suggestions on how to act when this occurs.
Notifying customers that the loyalty program is down using messages/alerts:
”There were problems handling your member/customer data. You can proceed with your purchase but will not be able to use your individual member/customer offers. This purchase will also not generate bonus points due to this issue. We are sorry for the inconvenience. Please contact Customer service for further info.”
Apply loyalty offers to all
As a kind gesture you can choose to open up general customer/member offers to all.
Note
No new contacts can be registered during this downtime.
To be able to tag transactions with a contact–id even though there is no possible communication to Voyado a secondary integration key should be implemented.
Normally we recommend that transactions are tagged with a contact-id: not personal information, such as a mobile phone number, but rather a Voyado-contact id, or a generic member number. Thus the POS or e-com must always take the public identifier (such as a mobile phone number or a social security number in Sweden) and check via the API which integration key should be used.
Our recommendation is to use one or more of the public identifiers, such as a mobile phone number or email address as a secondary integration key, that is, to tag the mobilePhone to the transaction instead of the primary integration key.
This is then matched as mobilePhone data in Voyado.
Example using primary integration key, in this case “memberNumber”:
{
"contact": {
"matchKey": "28972987289",
"matchKeyType": "memberNumber",
"contactType": "member"
},
"uniqueReceiptId": "2018468464468",
"receiptNumber": "468464468"
.......Example using secondary integration key, in this case “mobilePhone”:
{
"contact": {
"matchKey": "46707234567",
"matchKeyType": "mobilePhone",
"contactType": "member"
},
"uniqueReceiptId": "2018468464468",
"receiptNumber": "468464468"
.......Note
Bonus will be accounted for and bonus checks can be used when coded into the transaction.
Note
It is critical, as a GDPR-compliance, that the integration part get rid of local logging and temp storing of this integration data when it contains personal information. Voyado flushes integration logs and files after a certain time.
Note
No new contacts can be registered during this downtime.
A reasonably fresh database of Voyado’s contact-DB resides locally in the e-commerce platform and/or POS.
This is obtained via a primary data download from Voyado and incremental delta import via Voyado’s contact export XML. This export can be as complex or as rich as it needs to be:
A small DB containing only the possibility to check what integration key to be tagged to the transaction
Full-fledged contact object
Note
No new contacts can be registered during this downtime.
A reasonably fresh database of Voyado’s contact-DB resides locally in the e-commerce platform and/or POS.
This is obtained via a primary data download from Voyado and incremental delta import via Voyado’s contact export XML.
In addition to this it is possible to create and change contacts locally and sync incrementally to Voyado. This is obtained via delta export from the slaving part to Voyado via XML.
Note
In this case the integration key can not be the Voyado internal contact Id, rather a number sequence where new customers created in the slaving environment uses its own sequence level OR use a secondary integration key for this issue.