Hi,
I have a product where the customer can submit multiple transactions with different cards/bank accounts to pay down the balance. For instance if the product is $300, they can submit a $100 transaction, a $50 transaction, an $80 transaction, and a $70 transaction. They could pay the balance down in one transaction. There is no limit in how many transactions they use. After they make a successful payment in Authorize.NET, we should update the new balance that is displayed to them.
We are using the Accept Hosted solution with the redirect method (no iFrame/no lightbox) and with webhooks. The problem that we encounter is that the webhooks are not guaranteed delivery and are not instanteous, and the redirect after the receipt page is not guaranteed. So we run the risk of reporting to the user that they owe more than they really do.
One potential fix would be to have a tracking table and pass an ID from that tracking table as a querystring back to the returnUrl and store it in the refId part of the transaction. Then process the querystring and put the tracking table record in a PENDING status until the webhook is processed. We would need to put the record in PENDING when the payment was submitted. But in the Accept Hosted redirect method, the customer is only ever taken to the returnUrl if they click the "Continue" button on the Authorize.NET hosted receipt page. As I speculated and can confirm from this forum topic response, the customer may not be taken to the returnUrl if they close the tab or the browser/computer crashes (two very possible situations) and this would result in the tracking record not being put into a PENDING state even though the transaction was submitted. So if that last transaction that succeeded was for $50 out of a total $300 balance, we should be reporting to the user they only owe $250, but since we didn't update its status to PENDING, we still see it as them owing $300.
You may think, "ok well the webhook will be sent within that time it takes them to re-open the browser and login." This will probably be true but we still run the risk of our system timing out, Authorize.NET's webhook system timing out, or any other number of exceptions happening in which case the webhook may not be received before they login again.
09-06-2019 06:49 AM
09-06-2019 09:06 AM