What is an orphan payment?
The introduction of the SCA has consequences for the creation of your booking files.
The SCA can lead to the creation of so-called "orphan" payments, i.e. payments that are effective (the customer's card has been debited and the funds will be returned to you) but which are not linked to any booking file:
The customer has not received any confirmation from you
and no booking file has been created on your side,
no stock has been blocked.
Rest assured, these cases - beyond elloha's control - rarely occur. This article will help you 1) to understand the circumstances in which they occur and 2) what action you should take to ensure that they do not penalise your customer or your business.
How does it happen?
Until the introduction of the SCA, when a customer accessed your booking engine and entered their bank card for payment (or guarantee), the secure payment system (Stripe) carried out a "classic" check:
is the card valid (Yes or No)?
has the card been reported stolen or fraudulently used? (Yes or No)
does the cardholder's bank authorise the payment (sufficient funds, etc.)? (Yes or No)
When each question was answered with a "Yes", the transaction was authorised and the booking file was confirmed to the customer and to you.
With the introduction of the SCA, an additional step is imposed by the banks: in this case, that the customer confirms the payment via their mobile phone (code sent by SMS and/or identification by fingerprint or facial recognition). And this is where things get tricky.
For a variety of reasons, customers may not have their mobile phone 'to hand' and so will not confirm their payment immediately. Or they may not be able to do so instantly: the bank may not be able to send them the code, or their mobile phone may run out of battery... the reasons may be as numerous as they are funny.
In any case, if the payment (or the guarantee) cannot be confirmed by the customer, the booking will not be completed. After 15 minutes, in general (this time varies from one bank to another), the request for confirmation of payment is cancelled. In this case, elloha will also cancel the booking for non-payment.
In very rare cases (and this is certainly what is happening to you if you are reading this article), the customer may confirm payment for their booking at short notice. However, it is also possible that in this short space of time, elloha (seeing no confirmed payment) has cancelled the booking so as not to block stock that could be sold elsewhere.
This is the - again very rare - case of the 'orphan' payment.
To put it plainly, the payment is there but it is "orphaned" from a reservation file.
In even rarer cases - but it can happen! - the customer makes multiple confirmations and his bank (for reasons we do not know) will validate not 3 confirmations, for example, but 3 payments. In this case, elloha records not 1 but 3 "orphan" payments.
elloha can only observe these phenomena (which depend on the processes put in place by the banks, but also on your customer's responsiveness in authenticating his payment). When such cases occur (rarely), we can only alert you and the customer so that you can take the appropriate measures.
How is my customer alerted?
If you use the Stripe payment platform, elloha has the means to identify an "orphan" payment (a payment with no booking file attached) and to associate it with the contents of the shopping basket your customer was using (in your booking engine). In other words, we have no confirmed booking file, but we can 'trace' what the customer has booked.
In this case, we simultaneously inform :
your "customer": because their card has been debited but no booking file has been attached to it,
yourself (see below): so that you can contact the customer and manage the rest of their booking.
Your customer will receive an e-mail saying :
How will I be notified?
At the same time as your customer, we will immediately send you an e-mail alert to the address you have given us in your elloha account:
What should I do?
The important thing is to react for at least two reasons:
your customer has booked (this is the impression given to them by their bank confirming that the payment has been validated),
you have an assured and motivated customer whose expectations must be met by confirming their booking
You can do this by
Either by creating the booking using the "Customer on the phone?" function, which will have the advantage of blocking the stock and sending automatic confirmation to the customer. In this case, we recommend that you declare the booking paid (via your physical Eftpos terminal or any other means of payment). Under no circumstances should you use Stripe to pay, as this would trigger a new debit on the customer's card (which you would have to cancel yourself).
Or, if your stocks are unavailable in the meantime, by refunding the customer directly if you are unable to confirm their reservation. As the customer's funds have been debited from Stripe (and are on their way to your bank account), you alone are in a position to carry out this operation (under no circumstances will elloha be able to intervene in this process).
As mentioned above, there may be even more complex cases (which are also very, very rare) where the customer will have confirmed 3 payments to their bank and their bank will have confirmed not one payment but 3. In this case, it is highly likely that you will receive 3 messages relating to 3 "orphan payments".
The correct reaction is obviously to keep only one of the payments and to reimburse the other undue payments to the customer. Here again, as the funds have been collected by Stripe and paid (or are in the process of being paid) into your bank account, you have the funds available to reimburse your customer for payments that do not relate to a definitive booking.
Disclaimer
These phenomena affect a very small proportion of booking files (less than 0.4%) but they can create a number of constraints (confirming the booking "manually", refunding the customer, giving further explanations over the telephone, etc.).
elloha is not responsible for these situations, which arise from the introduction of the SCA and concern "borderline" cases (it happens!). In all cases, we give you both the warning and the keys to reacting in the best interests of you and your customer.