So, I have a payment form that I’m putting up to get the customer’s credit card information. I have a checkbox “save this card for future visits” to get the user’s permission, and since I"m going to be deploying this in Europe, I’m using the payment form’s verifyBuyer(…) call to get the additional verification token that will be needed in Europe. In the verification information that I pass into the verifyBuyer() call, there is an “intent” field which should be set to “STORE” for saving a user’s card, or to “CHARGE” for an immediate charge.
The problem is that I want to first save the card, AND THEN charge the card.
There are 4 scenarios that I can think of:
I don’t have a card on file for the user, and the user doesn’t want to create one.
I don’t have a card on file, but the user wants to create it, for current and future purchases.
I have a card on file and the user wants to use it.
I have a card on file but the user wants to use a different card, or replace the current one.
There are a couple of scenarios in there where I need to BOTH store the card for the user AND use it for the current purchase. This appears to be causing problems with the creation of the Payment for the current order, which is giving me the following error: “BAD_REQUEST: Invalid verification_token: INTENT_MISMATCH (Field: verification_token)”.
When I created the verificationDetails to send to verifyBuyer, I specified “STORE” as the intent, because I wanted to store the card, but then I get the error above when creating the payment. Should I use “CHARGE” instead, and will that verification token cause problems when I make the call to “CreateCustomerCard”?
Unfortunately the technical answer is: you would need to call verifyBuyer twice; once for storing the card, and once for charging the card (even with the card on file). In the future you would only need to do once if they’re using an already saved card on file.
Hi Stephen, thanks for the response! So I have a question … do I really need to call verifyBuyer before I store the card in the Customer record? Every time I use it (i.e. every time I do a card-on-file purchase) I’m going to call verifyBuyer for the card on file, so I will be meeting the requirements for validating the user at the time the charge is made. My understanding of the requirement for capturing the user’s information with the “STORE” intent was for future charges where the user was not present. I’m adding the support for verifyBuyer() into the code now, and this was all working before, so what I’m asking is: can I use the nonce generated by the payment form to store the card on file, and do the verify user for the “CHARGE” intent and use the card-on-file ID and the (“charge”) verificationResult when creating the payment?
I think that doing the verifyBuyer() call twice is going to really annoy the users.
I understand, and this has been brought up several times in the past. As far as I understand it when talking to our payment form team, this is a requirement by SCA policy, not something Square is enforcing. Currently with how it’s meant to work, you are supposed to call it twice (which I can see as being annoying).
The other unfortunate side of this is that since SCA really isn’t available in the real-world yet, we don’t know exactly how often banks will be requiring customers to validate their card. It could be possible that even while calling verifyBuyer twice, only one pop-up validation actually occurs, but that’s still to be determined since we can only test in sandbox environments currently.