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.
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. 
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).
any answers to my questions?
Hi @tbirnseth, while the charge is happening long after the customer has left you will still need to call verifyBuyer with the card on file. The returned tokens are one time use tokens so saving the verification information on file isn’t possible with SCA.
The values for the intent are in the Declare Verification detail object which are only CHARGE or STORE.
Is there a video or documentation that shows what happens when a buyer is verified (and any challenges)? I need to determine what functionality I can maintain and what I now have to throw away (and convince customers that it’s a good thing). If will verify with standard address info, that can be maintained. But if a merchant is doing an additional charge and it asks them for some data known only to the buyer it won’t work.
Is there a non-JS implementation of verifyBuyer? I.e. via the REST API. Many of these post-purchase charges happen as batch processing without any user interaction.
Unfortunately, a verifyBuyer via REST isn’t currently available. 
So the prior functionality of being able to charge a card based on a card-id without their being a browser based UI is no longer a supported feature? How do you propose a backend system charge a card on file then?
Charging a card on file is still available with the SqPaymentForm in regions that require SCA however you have to add the additional steps in the following guide to process the card on file payment.
What happens when a purchaser shouldn’t be checked (I.e. in the USA)? I’m accepting the verificationResult from a verifyBuyer will essentially be something that discloses to Square that the purchaser is alright? For example I can verifyBuyer() in any event, when it’s not needed and Square handles every one of the subtleties?