Making Website Integration More Robust

Take the example of our customer-fronting website that requires integration to a 3rd party payment gateway. We have a situation where there are 2 distinct websites, one dependent on the other to conclude the business process/ flow as well as some form of SLA from the 3rd party.
In essence, we do not trust the 3rd party payment gateway with our livelihood. How then do we integrate the websites together?
Here are some of the items we desire:

1. the 3rd party payment gateway appears integrated to our website
2. security and regulatory requirements are met
3. customers enjoy the entire website interaction
4. integration failure are monitored or at a minimum, logged
5. customers know what to do in the event of a failure (recovery or mitigation)

The current situation is that:

1. it is relatively easy to integrate with the 3rd party payment gateway, but
2. the payment gateway further integrates with other banks’ websites for 3DS

Assuming such a web flow:

1. our customer-fronting website (order information data entry page)
2. payment gateway (credit card data entry page)
3. banks’ 3DS website (pass-code entry page)
4. payment gateway (validated credit card confirmation page)
5. our customer-fronting website (deduction success/ failure page, committed order page)

The proposed solution is that we need to be more defensive (from defensive programming) – to anticipate – even assume – failures and mitigate against them. Some failures we anticipate are:

• website page failure
• network breakdown/ issues (given the unreliability of the internet as well as the customers’ internet connection)
• customer browsers’ or security settings
• unavailability of the payment gateway

While it is difficult – almost impossible – to monitor the progress after the customer leaves our website, we could at least monitor the closure/ end of the web flow. In general, we can treat every “dropped shopping cart” as a cause for concern and assume that it happens due to failure in website integration.
Another notable point, to ensure a reasonably good web experience, is to use a browser pop-up for the 3rd party website. This leaves our original site/ page (order information data entry page) intact for reference in case the website integration fails. For this to work seamlessly, our website needs to disclaim and validate that the browser pop-up feature is enabled.

In short, the recommended flow is:

1. check that browser pop-up feature is enabled (if required)
2. our customer-fronting website (order information data entry page)
3. order confirmation page as well as recovery/ contact details if the payment isn't successful
4. pop-up a window
1. payment gateway (credit card data entry page)
2. banks’ 3DS website (pass-code entry page)
3. payment gateway (validated credit card confirmation page)
4. our customer-fronting website (deduction success/ failure page, committed order page)
5. capture the completed transaction (checked-out shopping cart = no cause for concern)