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

I only see the newest example code. I’m looking for how to do the new SCA requirements within the older v2/paymentform. Not really excited to re-implement everything to account for EU requirements.

:wave: The information for SCA with the SqPaymentForm has moved with the launch of the Web Payments SDK. Here is the link to the SCA page. :slightly_smiling_face:

The link you provided simply times out and is inaccessible.

What I need is the SCA support in the SqPaymentForm API. Please advise where in the process the verifyBuyer() (or other) method should be called.

@tbirnseth Sorry about that the link is working now. Also all the documentation for the SqPaymentForm is listed in the Deprecated SDKs.

Thanks, the link now works.

Unfortunately I don’t see where anything related to the verifyBuyer() function supporting the new EU SCA is available from paymentForm SDK.

I would assume SCA would fall under the “critical security update” rules for supporting it in paymentForm.

Please advise.

With the SqPaymentForm there are two guides for SCA. One is Verify the Buyer When Using a Nonce for an Online Payment and the other is Verify the Buyer in a Card-on-File Charge.

What happens when a buyer does NOT need to be verified (I.e. in the USA)? I’m assuming the verificationResult from a verifyBuyer will simply be something that tells Square that the buyer is okay? I.e. I can verifyBuyer() even when it’s not required and Square handles all the details?

Okay, you’re going to hate me…

If a verificationToken is required for payments, do I need to store this with the card-id for post-order processing like adding additional shipping charges that were not known at time of order?

Or is Square saving the state of verifyBuyer() with the card-id so that the buyer only has to be verified once and I can charge against their card in the future (subscriptions, other charges, etc.)?

Any response to last question? It is an important business process need.
How long is the verification token valid?

When the intent is to STORE the card on file you will call verifyBuyer(). However when you go to charge the card on file you will call it again with the card_id to get a new token in this step of the guide.

but this charge is being done by the merchant. The buyer is long gone. So if there’s a challenge, how is it resolved?

Is there any detailed documentation about how it actually works? Seems that a stored card should have already verified the buyer and so when it’s used in the future, it’s already known the buyer is verified.

With current process, I store the card-id with the customer. if/when the customer needs to be charged additional amounts, the card-id is used. Pretty simple. But if there’s a challenge to personal information that the merchant may not have (or captured), how will they provide that data for the charge to complete?

How long is a returned token valid? Is it like a nonce and only used once? So many unanswered questions that are not documented.

Also, storing the card is not done in the frontend in my environment, it is done via the REST API.

Also, where are the allowed values for “intent” defined. Isn’t there somewhere that provides full description of the data and behavior of these newly required capabilities? Seems all my questions are valid and a result of missing or unfound documenation. You know, like a specification for frontend, backend and the data associated with the structures involved (type, enumarated values, etc.)? Similar as to how your REST API is documented (assuming that’s still available).