Handling of cancelled/declined payment gateway payments

[pricerc]

So I'm working through the test script for an EFTPOS integration.

I'd appreciate some guidance on what to do with the various possible 'failed' transactions.

I realise that there may not be a 'right' or 'wrong' answer for these questions, but I'm not sure where else to ask!

Scenario 1: fail before we start
Because I need to be able to recover at any point during the EFTPOS transaction sequence, I create the S/O payment with my own transaction reference just prior to starting the online transaction with the EFTPOS provider.

Now. Say at exactly this point - just between me creating the payment, and the next step of sending the request to the processor, there is a failure. Someone kicks the power cable out of the wall...

When the program restarts, I can see that I have a payment, but know nothing further. So I ask the processor, and get a "PJ", "Match TxnRef failed" response, telling me that my transaction never actually started (at least as far as the processor is concerned, so no money has changed hands while the computer was rebooting)

Do I delete the existing payment, mark it as declined and start a new one, or 'recycle' it by giving it a new reference number?

Scenario 2: transaction declined
My transaction is processed, but gets declined for some reason; the first one in the script is for a signature declined, but even a card read error is reported as a 'declined' transaction.

Is there a case for keeping the declined transactions, or can I just discard them? I'm a bit of a hoarder, so I would tend to go with keeping them, but I also know that in practice, the information is pretty much useless to anyone except the banks, who can get it from the payment processor anyway.

If I'm keeping then (In this scenario, or in the first one), what do I do with the payment values? Do I need to zero them out before saving the payments, or is the fact that they've been declined sufficient for Jiwa to account for them properly?

[Mike.Sheen]

This is a tricky problem, and if you've looked inside our "Paypal CC Processing" you'll see some rather crazy edge cases we need to cater for (Like for some reason an invalid CVV2 will mean you need to void the transaction by making another API call, whereas a plain card declined requires no such voiding). Exactly what edge cases there are and how to handle them depends a lot on the payment gateway API you are using (FYI Square and Stripe both have awesome API's).

Scenario 1: fail before we start
Because I need to be able to recover at any point during the EFTPOS transaction sequence, I create the S/O payment with my own transaction reference just prior to starting the online transaction with the EFTPOS provider.

Now. Say at exactly this point - just between me creating the payment, and the next step of sending the request to the processor, there is a failure. Someone kicks the power cable out of the wall...

When the program restarts, I can see that I have a payment, but know nothing further. So I ask the processor, and get a "PJ", "Match TxnRef failed" response, telling me that my transaction never actually started (at least as far as the processor is concerned, so no money has changed hands while the computer was rebooting)

Do I delete the existing payment, mark it as declined and start a new one, or 'recycle' it by giving it a new reference number?

I'd lean towards not deleting anything - keep an audit where you can - so don't delete, mark it as declined and start a new one. As I mention below - also set the ProcessPayment and the Processed properties to true to keep that payment locked and prevent it from being processed into a cashbook receipt.

Scenario 2: transaction declined
My transaction is processed, but gets declined for some reason; the first one in the script is for a signature declined, but even a card read error is reported as a 'declined' transaction.

Is there a case for keeping the declined transactions, or can I just discard them? I'm a bit of a hoarder, so I would tend to go with keeping them, but I also know that in practice, the information is pretty much useless to anyone except the banks, who can get it from the payment processor anyway.

If I'm keeping then (In this scenario, or in the first one), what do I do with the payment values? Do I need to zero them out before saving the payments, or is the fact that they've been declined sufficient for Jiwa to account for them properly?

I too would keep them - it *can* be useful when things do go as expected. When we first deployed the Paypal CC plugin at a customer we had the odd occurrence of payments being taken twice - and it wasn't until we modified things to be more hoardy that we managed to isolate the cause.

You don't have to zero out the payment - and it would be good not to - in case the reason for decline involves the amount - so instead set the ProcessPayment property to true and the Processed property to true - this way the payment is stored, but not sent through to the cash book receipt, and the sales order form will lock the payment record preventing edit. You'd also want to set the AuthorisationStatus to Declined and any other relevant info into the PaymentGatewayReturnCode and PaymentGatewayReturnMessage properties (which I suspect you already are).

[pricerc]

Thanks Mike.

The ProcessPayment and Processed properties will be the key I was looking for.

It's the WindCave (was DPS) API. It's probably similar to PayPal and Stripe. It's REST, so pretty much stateless, and the only information that I really need to keep for recovering from an error is my own reference number - the state of the transaction is maintained by them, I'm basically just tracking the status after the first purchase request has been sent.

[pricerc]

A related question.

Any suggestions on handling 'cash out' as part of an EFTPOS transaction ?

My initial plan is to just ignore it, because our pilot customer doesn't do cash out, but I figure sooner or later we're going to bump into someone who cares.

[Mike.Sheen]

A related question.

Any suggestions on handling 'cash out' as part of an EFTPOS transaction ?

My initial plan is to just ignore it, because our pilot customer doesn't do cash out, but I figure sooner or later we're going to bump into someone who cares.

Well, if you set the payment amount to the sales order amount, and the amount tendered to be that plus the cash out amount, everything works as you expect. You still have a cash book receipt entry for the amount (not including the cash out amount) and the other aspects like the journal for the sales order remain as you'd expect too.

Because you're dealing with cash then, you're going to want to do things like balance the till at least once per day, probably more - that is, reconcile the cash in the drawer with what the system thinks should be in there - so that reconciliation process would need to include cash out by looking at the difference. You'll also want a mechanism to set the cash "float" amount at the start of a shift, too.

In addition, you'll need to somehow flag a sales order as being captured on a particular physical cash drawer - so your till balance / recon reporting / process knows all it needs.