Refund payments with "CVV_NOT_CHECKED" & "AVS_REJECTED"

[Knowtifyd]

Hi Square community!

I've been getting customers reach out regarding multiple charges being made while trying to purchase items online.

Note:

1. I was originally using the Single-element payment form (since 06-01-2020) but I switched my client side application to use the Multi-element payment form starting on 03-03-2021 so that customers have the option to pay with digital wallets. This is when the error I describe below started happening.

2. The API version is 2021-02-26. payments are processed on the server using C# Nuget package Square9.0.0

Continuing: After investigating the root cause I've seen that the following happens.

1. Customer enters card information.

2. Taps "Pay Now."

3. Card is rejected. 

4. Customer knows their card has funds and something must have bugged out so they try again.

5. Customer repeats steps 2 - 4 after card is rejected.

(Investigation determined rejection occurred due to "CVV_NOT_CHECKED" & "AVS_REJECTED")

6. Customer repeats steps 2 - 4 after card is rejected.

(Investigation determined rejection occurred due to "CVV_NOT_CHECKED" & "AVS_REJECTED")

7. Customer tries one and final time - this time the card is validated.

I've seen this pattern happen a lot since using the Multi-element payment form and what's even less understandable is why customers are experiencing "CVV_NOT_CHECKED" & "AVS_REJECTED" the first couple times they attempt to pay online but then the 3rd time their card is approved. The end result is a customer is charged a total of 3 times (based on scenario described).

Question1: Has anyone experienced this issue before and what did you learn?

Question2: Should I accept payments with "CVV_NOT_CHECKED" & "AVS_REJECTED"?

Question3: Should I refund payments with "CVV_NOT_CHECKED" & "AVS_REJECTED"?

Note:

I understand "CVV_NOT_CHECKED" & "AVS_REJECTED" can result in fraud and chargebacks.

[nika · Accepted solution]

Hi @Knowtifyd! I'm definitely not an API expert, so I looped one in. Here's what I've got for you:

If the card is rejected but has enough information it's possible that the customer sees the charge on their card statement. However, if it's really a failure, the customer will not actually be charged (the money should be on "hold" but shouldn't actually be taken out). It sounds like maybe we're talking about two different issues here...

1. If the CreatePayment endpoint returns an error, the customer is not being charged.
2. If the CreatePayment succeeds, but also has AVS_REJECTED somehow, then it's up to you if they want to proceed. If you want to handle this more on your side, you can use autocomplete: false so you can see if it was rejected or not, and then make a decision about whether or not to complete it (calling CompletePayment) or canceling it (calling CancelPayment).

Hopefully this makes sense!

[Knowtifyd]

Nika_s, 

You've suggested an excellent solution regarding how to proceed after successfully calling CreatePayment yet somehow returns AVS_REJECTED. 

Thank you very much!

[nika]

All the credit goes to our API team! But I'm happy I could help relay the message. 😊 @Knowtifyd