Google Checkout callback delay causing duplicate payment

[artifacts]

It appears that after a user completes a Google Checkout, there is about a 20-minute delay before WHMCS sees a transaction from Google Checkout indicating that payment has been made. I think this is because Google Checkout gives the user 15 minutes after doing the checkout to change his mind and void the transaction.

 

After the user has clicked on the Google Checkout button, and completed the checkout, if he then clicks on the "return to example.com" link, he finds himself back at the same invoice that he just paid...and the invoice is marked UNPAID, as WHMCS has not yet recorded any payment.

 

At this point, the user may try to pay the invoice again. Neither WHMCS nor Google Checkout detects this as a duplicate event. The user can successfully pay the same invoice a second time without seeing an error messages.

 

Maybe this explains why people have been reporting (since mid-2007) that invoices got paid twice by Google Checkout users.

 

Rahul

[pacwebhosting]

Hi,

 

We used to take google checkout payments and the delay is while google clears the transaction and does some fraud checks etc..

 

next time you take a payment log into your google account and you will see its status it does not clear straight away in google checkout.

 

Paul

[artifacts]

...log into your google account and you will see its status it does not clear straight away in google checkout.

 

It's a bit more complex than that. Google Checkout immediately notifies the merchant's software (in this case WHMCS) that a new order is in progress. So WHMCS does know about the new order. But the new order does not become chargeable in Google Checkout until some time later.

 

In effect, Google Checkout progresses from UNPAID to PENDING to PAID. But WHMCS can only show an invoice as UNPAID or PAID. WHMCS has no state for an invoice called PENDING. So when the invoice really is PENDING (from the Google Checkout perspective), the user sees it as still UNPAID in WHMCS and may try to pay it again.

 

WHMCS's state machine doesn't have enough states to reflect Google's state machine. Google seems unlikely to remove any states from its state machine, so WHMCS will likely have to add some.

 

Rahul

[mylove4life]

If it's pending then it's not paid, so I don't see the piont...

[Jordan]

If it's pending then it's not paid, so I don't see the piont...

 

If you read what the OP wrote, he said that in Google Checkout (NOT whmcs) the process goes from unpaid, to pending, to finally paid. Whmcs will ONLY reflect paid and unpaid.

 

If a payment is pending in Google Checkout it will be "unpaid" in whmcs, which can inevitably cause the user to try to pay the invoice a second time.

[Matt]

So you want the invoice to be marked paid when a payment is only pending and could fail? Seems counter productive to do that as if it does fail you're going to have to go in and manually remove it. You could just add a message onto the invoice page saying "if you pay using Google Checkout it may take a few minutes to reflect the payment".

 

Matt

[PPH]

No, please don't try to change due to GC. Anyone using GC should know how it works and check their GC account for payment status. Simple notices for those that have a problem should take care of it, but we haven't had a problem to date. <knock wood>

[artifacts]

No, marking the invoice as paid while it's pending would be just as incorrect as keeping it unpaid while pending. In both cases we are trying to map three states on the Google side into two states on the WHMCS side.

 

The technically correct solution would be to show the invoice as pending on the WHMCS side so long as it's pending on the Google side. After a suitable period of time, either the invoice goes into a paid state, or if the payment failed, the invoice reverts to an unpaid state and the user gets an email letting him know that his Google Checkout failed.

 

Warning the user about a delay might work, but it won't prevent all duplicate payments, only some of them. People see too many warnings, and they tend to tune out most of them.

 

Rahul