Ecommerce Card Tokens failing: "CVV is not Provided"

Question

question

jms asked Apr 16, '21 retailcp commented May 4, '21

Ecommerce Card Tokens failing: "CVV is not Provided"

Hi, we just found an issue where customer multi-pay tokens are suddenly failing with the following response:

{
  "message": "402 Payment Required",
  "error": {
    "code": "card_declined",
    "message": "CVV is not provided",
    "charge": "<HIDDEN>",
    "declineCode": "issuer_declined"
  }
}

These tokens have been used successfully before to complete transactions, but suddenly they start throwing the above error with HTTP 402 Payment Required error code and the above message.

We found a following similar question: https://community.clover.com/questions/30005/payment-failed-when-using-same-payment-token-for-p.html

In the above question and the docs, it now says we need to pass the Customer UUID instead of the token or pass stored_credentials in the request.

We have been operating on production with Clover Ecommerce for around 8 months now and we passed the card token in the /v1/orders/{orderId}/pay as the `source` for the first request and subsequent payments. We have never had such an error and I can distinctly remember that it was the documented flow.

Q1: Can you confirm if this flow has now changed? Or was this always the expected flow? We had complaints from customers 1 day ago, around the same time the user in the above question faced the issue.

Q2: Are there any release notes or documentation that we can follow if such changes will happen in the future? This scenario has completely caught us by surprise.

Q3: How does Clover know which card to charge if the customer has multiple stored cards? Customer UUID uniquely identifies a customer, not a card right?

Q4: I do not see the stored_credentials in the documentation. Was it a workaround suggestion?

e-commerce api

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Welcome to the
Clover Developer Community

Answer 1 · 2021-04-16T13:40:12Z

David Marginian Deactivated answered Apr 16, '21 retailcp commented May 4, '21

Can you provide your app id in a private/moderators only post?

Please take the guidance I outlined in my answer in the link you posted - https://community.clover.com/questions/30005/payment-failed-when-using-same-payment-token-for-p.html.

Q1, Q2 - I will provide you with answers to these questions in a follow-up post.

Q3 - When passing the customer uuid as the source, it is assumed there is only a single card on file.

Q4 - stored_credentials is not currently mentioned in our tutorial documentation but it has always been in the REST API Reference - https://docs.clover.com/reference#createcharge.

6

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

jms commented · Apr 16, 2021 at 06:52 PM

Thanks @David. Regarding the following suggestion:

Q4 - stored_credentials is not currently mentioned in our tutorial documentation but it has always been in the REST API Reference - https://docs.clover.com/reference#createcharge.

This is simply used to charge a card right? This charge won't automatically apply to any order unless we have another request to attach this charge to an order right?

0 ·

David Marginian ♦♦ jms commented · Apr 16, 2021 at 08:18 PM

Passing stored_credentials will not result in future payments. Each payment would require an additional request with stored_credentials set.

0 ·

jms David Marginian ♦♦ commented · Apr 17, 2021 at 04:27 AM

I think I didn't phrase that question right. What I mean is that there are 2 ways to charge using e-commerce. One is https://docs.clover.com/reference#createcharge and the other is https://docs.clover.com/reference#postordersidpay.

While the former supports the mentioned stored_credentials field, it doesn't allow us to attach the payment for an order.

The latter request is what is documented to be used to pay for an order (so that the order will show up as paid) but according to this current state, it has suddenly stopped supporting multi-pay unless it's just one card per customer and we pass customer uuid in the source.

Hope that is clearer?

0 ·

David Marginian ♦♦ jms commented · Apr 17, 2021 at 12:02 PM

We recently released merchant fraud tools which allow a merchant to automatically void card not present payments if there is a CVV error, AVS problem etc.. The defaults are to void payments for CVV errors (which I think you will agree makes sense).

A bit of explanation about card not present payments will help understand why this is causing problems. Per PCI the CVV cannot be included in the card token. When a card is tokenized we keep the CVV in cache for a short period of time (~10 minutes) and wait for a payment with said token so we can validate it. After that period if a payment is made with the token in question it will be rejected (per merchant fraud tools), previously we still accepted the payment but returned a CVV error in the response.

Obviously, the scenario above doesn't work for card on file. Since the token won't have the CVV - we can't validate it. So, we need to know that the payment is recurring (so we can skip the validation) and when you pass just the source token we have no way of knowing. When you pass the customer UUID as the source that indicates a recurring payment and we set the stored_credentials automatically. This is a failure in our documentation, where we didn't clear state that customer UUID MUST be passed for recurring payments and we are addressing this.

So, in summary you must either pass the customer uuid as the source for recurring payment requests OR pass stored_credentials:

{
    "source": "{yourtokenhere}",
    "stored_credentials": {
        "sequence": "SUBSEQUENT",
        "is_scheduled": "false",
        "initiator": "CARDHOLDER or MERCHANT"
    }
}

The ecomm team tells me (I haven't had a chance to try it) this is supported for the order/pay endpoint as well, even though it isn't in the REST API.

Does this clear things up for you?

1 ·

jms David Marginian ♦♦ commented · Apr 23, 2021 at 08:19 AM

Hi @David, thank you for providing a quick resolution to this problem. We applied it to production and card on file works now without issues.

It would be nice if this was emulated on sandbox as well so that we might have caught it during testing phase. This obviously is a necessary feature no doubt, it just caught us suddenly by surprise and no warning.

Best Regards

0 ·

Show more comments

Answer 2 · 2021-04-16T20:07:10Z

wsadiq answered Apr 16, '21

We have also started seeing high number of "CVV is not provided" errors since 4/14. Has anything changed? We allow customers to store multiple credit cards, tokenize the cards using iframe method and our code follows the process described in the "Saving the card for future transactions". When the order needs to be paid, we follow the exact instructions as described in "Paying for an order". This was working fine until 14th.

We are also getting complaints form the merchants because customers are not able to pay for their orders. Please advise.

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

Answer 3 · 2021-04-22T19:21:27Z

01928-7325x2 answered Apr 22, '21 01928-7325x2 commented Apr 23, '21

We also having the same issue.
It just a sudden change on Clover side?
So, how about all the previous saved card?

Cannot be used anymore?

4

10 |2000

Attachments: Up to 2 attachments (including images) can be used with a maximum of 512.0 KiB each and 1.0 MiB total.

David Marginian ♦♦ commented · Apr 22, 2021 at 07:26 PM

Per my comment below:

We recently released merchant fraud tools which allow a merchant to automatically void card not present payments if there is a CVV error, AVS problem etc.. The defaults are to void payments for CVV errors (which I think you will agree makes sense).

A bit of explanation about card not present payments will help understand why this is causing problems. Per PCI the CVV cannot be included in the card token. When a card is tokenized we keep the CVV in cache for a short period of time (~10 minutes) and wait for a payment with said token so we can validate it. After that period if a payment is made with the token in question it will be rejected (per merchant fraud tools), previously we still accepted the payment but returned a CVV error in the response.

Obviously, the scenario above doesn't work for card on file. Since the token won't have the CVV - we can't validate it. So, we need to know that the payment is recurring (so we can skip the validation) and when you pass just the source token we have no way of knowing. When you pass the customer UUID as the source that indicates a recurring payment and we set the stored_credentials automatically. This is a failure in our documentation, where we didn't clear state that customer UUID MUST be passed for recurring payments and we are addressing this.

So, in summary you must either pass the customer uuid as the source for recurring payment requests OR pass stored_credentials:

{
    "source": "{yourtokenhere}",
    "stored_credentials": {
        "sequence": "SUBSEQUENT",
        "is_scheduled": "false",
        "initiator": "CARDHOLDER or MERCHANT"
    }
}

The ecomm team tells me (I haven't had a chance to try it) this is supported for the order/pay endpoint as well, even though it isn't in the REST API.

Does this clear things up for you?

0 ·

01928-7325x2 David Marginian ♦♦ commented · Apr 22, 2021 at 07:49 PM

Where developers can find the documentation about this change? Or any email sent out to developer about the change?
I'm wondering if I missed it.

0 ·

David Marginian ♦♦ 01928-7325x2 commented · Apr 22, 2021 at 07:51 PM

You didn't miss it, it is a change for merchant's that impacted devs that weren't using tokens correctly. Unfortunately, our documentation wasn't super clear and we are correcting that.

1 ·

Show more comments

question