Is there an example of SCA wth v2/paymentform API?

Questions
21

Bryan, I think you missed my point. The charging of a card is not done in the front-end, it is done in the backend without any UI or user interaction. I.e. there’s no JS active. Hence the need for a REST version of verifyBuyer(). I’m also going to list my current process for deailing with nonce and saved cards. I would appreciate it if you could describe how to do this in the newer environment.

22

Hi Bryan, current business process is this:

Frontend:

  • acquire a nonce and place it in a form that is submitted to the back-end along with other info needed in the backend.

Backend

  • If the customer is an existing customer (not an anonymous checkout) then the nonce is used to create a square customer (if they dont already exist).
  • The nonce is used to save the card to the customer in Square which returns me a card_id
  • The charge is made against the card_id (but now I won’t have a corresponding verificationToken for a charge intent).

Issues as I see them:

  1. the verifciationDetails requires an “intent”. If I use the “intent” as SAVE then I can’t charge the card_id in the backend using the same verification token. If I use the intent as CHARGE then I can’t save the nonce as a card in the backend.
  2. The backend is using the REST API and the architecture of the CMS is to actually process the payment in the backend, not the frontend. This is also true for creating square customers, creating/managing cards, etc.

How do I deal with both “intents” when I’m starting with nonce but then using card_id after it is saved to the customer? Is there a “both” or “charge-save” Enum for intent?

Am I supposed to change an entire business process/workflow to account for verifyBuyer() intents that are only in use in some parts (not a large part of my customer base) of the world (EU/UK)?

Please advise how I’m to solve my problem. Not everything related to card transactions is done within a UI and/or in the portion of a workflow where a UI is even avaiable.

23

What happens when a buyer shouldn’t be checked (I.e. in the USA)? I’m tolerating the verificationResult from a verifyBuyer will basically be something that unveils to Square that the buyer is okay? For instance I can verifyBuyer() regardless, when it’s not required and Square handles all of the nuances?

24

As I read the docs, you are correct. In USA (and most of the world) it’s basically a no-op, but still required! So we must all succumb to the wishes of the EU/UK.

25

Hi Bryan, I’m still awaiting a response on the following:

  1. How to solve the workflow problem related to saving customer/cards when that is done in the backend via the REST API.
  2. Is there a plan for a solution to the problem where a card can’t be charged without it involving the browser (I.e. a batch or backend process)?
26

Currently, there isn’t backend via REST API for the verifyBuyer and you will need to have some function that calls verifyBuyer to get the verification token. As for plans to for additional solutions there isn’t any plan to change this flow with the SqPaymentForm as its deprecated.

27

And what about NOT using the SqPaymentForm given the same issues apply? This is NOT specific to SqPaymentForm. I.e. the same issues exist in the web-payments method too.

So what you’re telling me is that there is no way to process a credit card payment anymore without it being initiated from a browser. I.e. no batch or backend processing. And there is no workflow that allows for a card_id to be created from a NONCE using an “intention” of SAVE and then to be able to use that card_id to initiate a charge (“intention” of CHARGE). I.e. I have to create the customer from the browser AND I have to save the card from the browser AND can then submit a card_id and verification token to the backend for an actual CHARGE.

There now appears to be no way to implement a subscription process that may have a variable rate. Ouch.

It appears that your developers did not really think through the business processes in place with your existing implementations. So at this point, my customers are going to think I’m ripping them off by removing functionality and Square is going to look bad for no longer supporting functionality they had in the past. Bad situation for all.