Introduction
The proposed new feature aims to enhance the user experience during the payment process by ensuring that the transaction is completed without interruptions. When the user places an order, the system will prevent them from closing the page until the payment processing is complete. This measure aims to significantly reduce errors and frustrations associated with interruptions in the payment process, offering a smoother and more satisfying shopping experience for customers.
Context
CURRENT BEHAVIOR
When the user places an order (presses the button), the button state changes to a loading state, blocking the user from pressing it again. However, the rest of the page does not change or block, allowing the user to return to the previous step in the middle of the process (pressing X to close).
RISKS OF CURRENT BEHAVIOR
Allowing the user to go back during the payment process is a risk because the payment is an important step that involves Payment and RBI platforms. Their interruption leads to several errors, depending on when the user closes the page.
Goal
The goal is to block the user's ability to close the page while the transaction is being processed. By blocking the ability to close the page during payment processing, we hope to minimize errors and dropouts, providing a smoother and more satisfactory purchasing process for customers.
This feature has a flag called Enable Processing Payment Splash Screen which should be enabled to be used. Key of feature: enable-processing-payment-splash-screen
PSP’s can enable this feature with this flag: Paycomet, Paymark, Adyen
To enable, this flag please contact your CSM.
PSP’s enabled all the time (There isn’t flag): Cybersource, Checkoutdotcom
For others PSP’s there isn’t this feature.
CHASE, WORLDPAY, and PLACETOPAY PSPs there aren’t any payment flows in the Whitelabel code until this moment, but the payment processing loading will be added later;
Out of the scope
FIRSTDATA, ORBITAL, FIRSTPAY and VRPAYMENT;
Paycomet:
Redirect the user when clicking on “Cancel“ inside the popup:
If the user chooses to close the popup, the payment page enters an infinite loading state, with no completion. This behavior forces the customer to take drastic actions, such as closing the page and redoing the flow, which interrupts the purchase flow and can potentially cause frustration.
To solve this problem, we will capture the user's action of closing the popup and, when this happens, they will be redirected to the cart page and a new OrderId will be generated, consequently generating a new TransactionId.
There is also the possibility of closing the popup inside the iframe (Bizum and PayPal);
There isn't a cancel button or close button inside the Waylet iframe popup.
Redirect the user when clicking on the “close button“ in the popup:
This button remains enabled throughout the transaction process, which may allow the user to cancel (by clicking this button the user is redirected to the cart) the purchase for any reason, such as a simple delay in payment processing or any other non-apparent reason.
Show the splash screen loading on the payment flow
Payment with Card (Onetime - First payment)
Payment with Card (Vaulted - Card saved)
Payment with Popup (Paypal, Waylet and Bizum)
on-close event and unexpected closes (Infinity Loading issue)
Currently, when the user closes the popup by the close button or in an unconventional way, the page gets into an infinite loading state. This problem occurs only with payment flows that involve a popup.
If some time the Popup unexpectedly closes, the page will show the modal informing a specific error:
The message errors can be changed to Lokalise, in the keys:
Title: uhohSomethingWrong
Description: paycomet.error.9999
Button: goToCheckout
ADYEN and PAYMARK there is not a payment flow with popup or modal, so it doesn’t need to do the validations like Paycomet
Adyen
Payment with Card (Onetime - First payment)
Payment with Card (Vaulted - Card saved)
Paymark:
Payment with Card (Onetime - First payment)
Payment with Card (Vaulted - Card saved)