When a payment is completed, does the gateway send the customer to the return URL immediately or does it wait for a registered webhook to be serviced first.
Basically this question is asking whether the "async" reporting is truly async or whether the first attempt is synchronous with the gateway, giving time for the partner to process the webhook and set up state before the customer is returned, so that when the customer arrives a completed state can be shown without trusting the customer merely showing up at the return URL without even processing the payment.
If the first webhook is synchronous, that's great, it makes things easier on the average partner. If the first webhook is asynchronous and the gateway returns in parallel, then that's great too because the customer gets a quicker round-trip-time, but then the partner's result page needs to poll for success.
Which is it, and what's the timeout if it is synchronous? The only timeouts in the Docs are generic and say up to 60 seconds - which is way too long to keep the customer waiting if for some reason the first "async" webhook took a long time to reply.
Apologies for the delay in response
Once the payment is successfully done via the Chargebee’s checkout page, Chargebee redirects the customers to the Thank you page or the URL that you have configured for your customers to be redirected to.
The checkout process is synchronous with the gateway, and will only display a "Payment Successful" upon verification from the respective gateway. This process is a swift one and will take a few seconds at most. The redirection also happens after the successful payment.
Hope this clarifies.
Thanks Prajit. You've told me exactly what the gateway docs already say, but you haven't answered my question.
Yes or no - will webhooks fire to report the transaction status to the integrating partner's website before the gateway redirects the customer back to the integrating partner's website?
Yes means that the integrating partner can reliably show a Success page when the customer arrives.
No means that the integrating partner must poll the Chargebee API to determine the state of the transaction before reporting success to the customer, but the redirect happens slightly faster.
Which is it?
The redirection will happen only after a successful checkout and the webhook will be fired at the same time(as soon as the checkout is successful). Redirection to a thank you page signifies a successful checkout.
Hope this clarifies.
It almost clarifies.
If the integrating partner is meant to trust the redirection as proof of successful transaction then, apart from the customer arriving at the redirect URL, what steps can the integrating partner take to formally prove that the customer didn't arrive at the redirect URL without actually completing the transaction? Where's the fraud mitigation?
It is not necessary for the integrations partner to just rely on the redirection process as proof of the successful transaction. As we mentioned earlier, webhooks can be used and the payment_succeeded webhooks are triggered only after a successful transaction. In case there's a failure or timeout during the checkout, the customer will not be able to complete the checkout process and the redirection will not happen.
Chargebee will never redirect the customer to a different page without processing the transaction. We also have an integration with Stripe Radar which helps you detect fraudulent transactions. You can read more about this here.
Thanks for acknowledging the concern I have with no security in the return URL. It wasn't part of the topic, but it is important.
We have a Shared Secret with Chargebee. Actually we have several. One is the HTTP Basic Auth which Chargebee uses for the webhooks to verify that those responses are not forged. it would be lovely if we could get the return URL securely signed using that secret so that we can trust the returning customer URL directly, since that would accelerate the customer experience and reduce integration steps.
ie at checkout time: (example PHP code)
$return_url .= '&transaction_id=' . $transaction_id;
$return_url .= '&amount=' . $amount;
$return_url .= '&u='.time();
$return_url .= '&nonce='.
$return_url .= '&sign='.substr(sha1($return_url.$basic_user.$basic_pass),0,32);
Then the integrating partner could check the URL components match expectations (ie values match session), verify the digital signature is correct and the time window is small. Then we could show the success/thanks page instantly without needing to resort to polling.
Of course, this would be even more secure if we signed the inbound request to the payment gateway as well so it also can't be tampered with, and then success means the same thing it meant when we sent the customer to you. ;-)
Perhaps you could pass this recommendation along.