402 Invalid CVC when creating customer with eComm payment token

Question

question

carwashreports asked Mar 20, '22 carwashreports commented May 9, '22

402 Invalid CVC when creating customer with eComm payment token

Hello,
I have an application that currently allows for signing people up for monthly membership plans. We are on the Clover Flex Gen 2 only. During the sign up flow we currently open up a WebView that has a EComm iFrame in which the CC info is manually entered. Once this form submits a token back to our server we create a customer and save this token on file in order to have a multi-pay token, following the directions here: https://docs.clover.com/docs/ecommerce-saving-card

To make the sign up process easier we are trying to use the Rest Pay Display API in order to get the eComm compatible token instead of the manual form entry via iFrame. We are using this endpoint: https://docs.clover.com/reference/request_token

For some reason we are getting back a 402 when taking the token returned from the Rest Pay Display API and attempting to create a customer:

%{"error" => %{"code" => "invalid_cvc", "message" => "CVV not found during card verification for Clover token clv_1TSTSqeJUN9uekt2gce6aEnx", "type" => "card_error"}, "message" => "402 Payment Required"}

Is this expected? I've seen other posts in the forum about this error but those seem to be related to using the token directly for payment multiple times. We are only trying to post the customer right now, and doing this exact flow with the iFrame approach works fine. Are we missing a step in order to use the token returned from the Rest Pay Display API?

Also, is there any way to enable a button to exit the Clover Pay Display API? Currently on success/error we just have it display a message but the device just hangs. The 4 corner touch to exit is not the easiest approach, have to do it multiple times as it doesn't sense all 4 touches every time.

Update: So I did update the initial request to get the token to include manual entry as an option. Not sure if this matters but I was testing with the provided test card that came with the Flex device, is that an issue? I manually enter in the success Discover card from here: https://docs.clover.com/docs/testing-us-payment-flows, looks like it gets past the 402 response but we do get a 500 now:

body: %{
                  
     "code" => "processing_error",
     "message" => "There was an error communicating with the server. Please try again.: TokenizationResult: null",
     "requestId" => "e0747e54-ec97-4a10-af33-b4c89f6c484b",
     "requestType" => "REQUEST_TOKEN",
     "type" => "api_error"
   }

REST API ecommerce

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 · 2022-03-20T20:40:31Z

David Marginian Deactivated answered Mar 20, '22 carwashreports commented May 9, '22

A token needs to be used within approximately 10 minutes of being created. You shouldn't be using the ecomm API from a native app. What is your app id?

17

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.

carwashreports commented · Mar 20, 2022 at 09:48 PM

In this case it is being used within 10 minutes. We are not making the calls to the EComm API from the native app, they are happening from our backend server. Our app has a native app to provide industry customized checkout flows for car washes (does things like LP scanning, menu in a way that is specific to car washes, etc.). Orders and memberships submit to our backend server where we provide some custom reporting and handle the monthly billing of members via the EComm API.

In this scenario a customer selects a monthly membership plan, in the native app we collect their info. Vehicle, name, package, etc. We submit this info to our backend which saves it and then makes a call to the Rest Pay Display API to get a ecomm compatible token. The returned token needs to be used to bill this customer once a month for their membership, so we need to set it up as a multi-pay token. As soon as the response token from the Rest Pay Display API comes in we make the request to set it up as a multi pay token. However when making that request to set it up as a multi pay token we are getting the error responses, 402 and 500.

0 ·

carwashreports commented · Mar 20, 2022 at 10:06 PM

Do you recommend a different approach for this use case? Currently we have everything working, it's just instead of using the Rest Pay Display API we are using the clover hosted iFrame to get the token: https://docs.clover.com/docs/using-the-clover-hosted-iframe

This works, but being able to just tap a card on the Flex would be a much easier user flow and multiple people have asked for it to work that way. Using the Rest Pay Display API was the only way we could find in the docs to try to do something like this.

0 ·

David Marginian ♦♦ carwashreports commented · Mar 20, 2022 at 10:53 PM

It sounds like because we provide no way of natively obtaining an ecomm token that you are being forced into a workaround. Using RPD isn't ideal because the app is meant to be customer facing and cannot be cleanly exited. To work around that problem you are launching an iframe from within a web view. Am I correctly understanding the problem? I think we are working on a way to be able to get a token via the Android SDK, let me check on that, give me a few days.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 20, 2022 at 11:10 PM

Yes you are correct, if we could retrieve an EComm compatible token natively that would be way easier. We wouldn't need either the iFrame or RPD, just request it locally on the device and then submit it to our backend for use with the monthly billing through EComm api calls there.

I had asked about it before on the forum but they had directed me to use RPD, maybe my explanation was not clear at the time.

0 ·

David Marginian ♦♦ carwashreports commented · Mar 20, 2022 at 11:33 PM

RPD is really the only option I am aware of right now. Let me see what I can find out about the availability of a native solution.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 21, 2022 at 01:51 AM

Thank you, really appreciate the help.

In the meantime, in case RPD is the only option, are we using RPD incorrectly? On sandbox we get the 402 response if we swipe the test card, and a 500 if we key in the clover provided test card numbers. Based on the docs though I don't see what we could be missing to cause these responses.

0 ·

David Marginian ♦♦ carwashreports commented · Mar 21, 2022 at 09:15 AM

I need to look into this more. I think the token returned by RPD will be multi-pay by default, have you tried using it directly to make a payment (not creating a customer with it?).

0 ·

carwashreports David Marginian ♦♦ commented · Mar 21, 2022 at 04:59 PM

Your right that does seem to work. I guess the docs do say the endpoint can return a single use or multi-pay token: https://docs.clover.com/reference/request_token

I'm guessing specifying tokenType = ECOMM_COMPAT makes it a multi pay token. I was just confused because with the iFrame approach we get a Ecomm token but have to manually make it multi pay.

A few minor follow up questions related to this:

1. On sandbox env we see an occasional 502 Bad Gateway or a 503 Down for maintenance error, these don't seem to match any posted maintenance times or announcements. Any known issues regarding these? We have not seen these in production ever, only in sandbox.

2. This approach seems to work, our BE makes the RPD request and then we can just tap the card and complete the membership sign up. The one quirk that has come up though is if the Clover Pay Display app is not open and running in the background, the first time you do a RPD token request it initializes and stops at the Welcome screen, it does not perform the tokenization request. Any known work around/issue related to this? Can see it happening often where customers will forget to make sure to start the Clover Pay Display app in the background and then the first tokenization request gets stuck. Being able to request the token natively would be easiest here, but in the meantime if we can get RPD working we can proceed.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 22, 2022 at 12:48 AM

Following up on this with another question. Previously we were using the iFrame to get a payment token and then converting the token to a multi pay token. In order to convert to a multi pay token we had to collect:

- customer first name
- customer last name
- customer email
- customer phone number
- customer street address name
Then additional fields that our application required like the vehicle info for the membership.

With RPD we can get a multi pay token without having to convert ourselves, does this mean we do not need to collect all this info? Previously we were told this info is required to be kept on file for EComm API billing, but it seems that is only for the conversion to multi pay API call: https://docs.clover.com/docs/ecommerce-saving-card#saving-a-card-for-a-new-customer

If we use RPD, can we only store the customer first name, phone, and email and satisfy requirements for re-billing customers through the eComm API?

0 ·

David Marginian ♦♦ carwashreports commented · Mar 22, 2022 at 01:21 AM

1) Sandbox doesn't have the same redundancies as prod so from time to time transient errors may occur.

2) You are using Cloud Pay Display, is that correct? You can't use both RPD and CPD. Is this happening in prod and sandbox?

3) I don't see any reason why you need to gather all of that customer data. The approach you were taking with the ecomm API requires that info because a Clover customer was being created.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 22, 2022 at 01:38 AM

Yes on the sandbox Flex device we have Cloud Pay Display installed and open when making the request. We are using this endpoint: https://docs.clover.com/reference/read_card

When we hit that endpoint with the device serial number, it does bring up the card tokenization flow. From our testing this token is able to be used multiple times in the sandbox env.

Is this not supposed to work like this?

0 ·

David Marginian ♦♦ carwashreports commented · Mar 22, 2022 at 11:34 AM

read_card? You should be using https://docs.clover.com/docs/creating-a-card-token to obtain a token.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 22, 2022 at 09:06 PM

My mistake I had the wrong URL, we are using this endpoint: https://docs.clover.com/reference/request_token

When we hit request_token, it opens up the Cloud Pay Display app on the sandbox device.

From the doc you linked (https://docs.clover.com/docs/creating-a-card-token) it talks about using legacy card tokens. Do these include the tokens vaulted on devices with Payment Connector? From here: https://docs.clover.com/docs/vaulting-cards

If so, I can use PaymentConnector to vault a card natively if we are able to use those for subsequent charges afterwards? Or would that not work with the eComm API?

0 ·

David Marginian ♦♦ carwashreports commented · Mar 22, 2022 at 09:09 PM

Those tokens do not work with our EComm API.

0 ·

carwashreports David Marginian ♦♦ commented · Mar 22, 2022 at 09:22 PM

Okay, so for now our best approach is to use RPD and Cloud Pay Display. You mentioned earlier:

2) You are using Cloud Pay Display, is that correct? You can't use both RPD and CPD. Is this happening in prod and sandbox?

The calls to RPD do launch the CPD app on the device, tried that based on this doc: https://docs.clover.com/docs/configuring-a-cloud-connection

Is this not supposed to be happening?

We did notice a difference when testing on our sandbox account and our production account (we have our own live car wash that uses our app). On sandbox when we make the RPD API call the Cloud Pay Display launches automatically and takes over the Flex device. In production, the app does not launch automatically and take over. We have to manually switch apps to it in order to try and tokenize a card. This would make for a bit of an awkward UX in Prod, switching between apps. Should Prod CPD be taking over the device like it does on Sandbox?

Also regarding a native Android method for EComm tokenization, any idea on a possible timeline/if this is being worked on?

0 ·

David Marginian ♦♦ carwashreports commented · Mar 23, 2022 at 12:50 AM

CPD should auto-launch. The native tokenization is scheduled for release in production in June.

0 ·

carwashreports David Marginian ♦♦ commented · May 09, 2022 at 10:51 PM

Hi David, I wanted to follow up on this and see if the timeline is still for a June release for native ecomm tokenization from Clover devices? Is there any beta testing group that we can get access to for this functionality?

0 ·

question