How to handle shoppers that do not return to the shop after payment?

Follow

Use case

  • The shopper does not successfully return to the shop after payment (ex: closes browser). The merchant regardless wants notification of the transaction's final result.

Solution

  • Before the session times out, and if there was no GetStatus call yet executed, COPYandPAY calls the shop's result page, just as the shopper would do if properly redirected.
  • The shop then calls the GetStatus-URL which returns the JSON-formatted transaction results as response.

Let’s walk through the steps

Step 1:

You will receive the notification from COPYandPAY just like if a shopper had completed the process normally: a call to the return URL as configured in the payment form. The only difference is that this call doesn't come from the shopper's browser, but from our servers. As in the usual workflow, the merchant should call GetStatus with the token from the notification call (same token as used for the payment).

Step 2:

You will receive the response from the GetStatus, just as in the traditional workflow. It should be treated like a normal shopper call.

FAQ

Is this call a security threat?

  • This is not a security threat, it is just a server to server call to the return url you've configured in the payment form. The notification call is empty, no other information or paramters are added. You actively have to request (pull) the status from our server. In case a third party would acquire the token and trigger the call, the potential attacker still wouldn’t be in the chain of the GetStatus-request/response.

How long does it take to receive this call?

  • The call might take up to 20 minutes.  The length of time for the call delivery depends on several factors, including the payment method that the shopper abandoned's time out tolerances.

What do I have to do to integrate this?

  • The main difference is that the call comes from the COPYandPAY servers instead of being triggered directly by the shopper, thus this workflow needs to be IP whitelisted (if needed) and scripted against due to the potential for the call to be delayed.
  • A possible consequence of this is that the shopper's session is lost. This is especially true when relying on browser cookies. The recommendation is to use a session-identifier as part of the return-url – thus this reference would be returned with the GetStatus call for further action (ex: notify user of abandoned payment).
Have more questions? Submit a request

Comments

Powered by Zendesk