The checkout call is used to process payments and create orders. There are many different endpoints, depending on which application or sale channel is being used. The driver for selecting a checkout endpoint should be, “to which sale channel do I want this sale attributed?”
While the checkout object is mostly the same across all sale channels, there are some slight differences depending on the endpoint you use. This section will provide information specific to each checkout endpoint.
Preventing B2C Credit Card Phishing Attacks
The unauthenticated consumer ticket/membership sales flow for B2C API implementations is regularly subject to attacks from spammers who will try if a card authentication works via a charge and then go on to charge that card found valid into other online stores, or anywhere else.
Those attacks often are caused by bots and end up creating an unnecessary rather large transaction cost on the merchant of record (MOR) given that attacks happen in bursty large batches. When ACME is the MOR, it reserves the right to turn the B2C API traffic in order to avoid incurring those costs. When ACME is not the MOR, we want to make sure that our checkout infra provides the ability to protect the MOR via preventing such attacks.
Our prevention mechanism is currently based on an invisible ( read no buying dropoff) CAPTCHA mechanism whereby external AI underneath our stack does score a safety number based on the different browser patterns (IP, cookies, etc…).
We require our B2C API implementation to insert Google Recaptcha v3 into their payment pages and pass the captcha token to our checkout API.
Please use this Google documentation for your JS coding.
The captcha public key for production is 6LfTvpgUAAAAABCSDZOLtww0i8C4Ug-3m_WbS4Mf
For the sandbox environment, it is 6LcFf5gUAAAAAJCGROIYJvD2BxgvqKvCSGmxDvKU
Once you get the token from the Google JS, you only need to pass it as an http header called “x-acme-captcha-token” into our checkout API , wether called from the browser or from your server.
Before this functionality can work you will, however, need to talk to our API support team so that the client facing URL can be white listed in our infrastructure.
Note as an example one of our clients that built a single screen donation page https://www.huntington.org/donate in order to view how the Google JS is called.
Please note that if you are the MOR, you may decide to use your own card phishing prevention mechanism. We do however recommend our fraud prevention system given it collects data for all of our clients at once and leverage the AI algorithms of Google at scale, therefore it should detect attacks on your site much faster thanks to a larger training data set.
Preventing Duplicate Charges
A common issue that developers run into when building custom integrations is with users being charged twice or multiple orders being created at checkout. We have a couple of best practices to safeguard against this issue and to help avoid the need for emergency code changes in your integration.
Request UUID Header
We strongly recommend generating a UUID for each checkout transaction and sending that via theheader. If the backend sees two back-to-back checkout attempts with the same UUID, it will reject that transaction as a duplicate and return a DUPLICATE_TRANSACTION error.
The other strategy we recommend is to prevent users from creating duplicate transactions via your front end. Strategies include blocking the “submit” or “checkout” button after it’s been clicked or providing visual feedback to the user that the request is in process. The most common cause of duplicate orders is users thinking that “nothing’s happening” and clicking the “submit” button multiple times.
Providing visual feedback that the click was successful and the order is being processed is very effective in preventing duplicate transactions from being submitted to ACME.