we created an authorized payment (autoComplete=false) with apple pay, and got below error when we tried to update the amount of this authorized payment.
[Error [category=INVALID_REQUEST_ERROR, code=BAD_REQUEST, detail=amount_money cannot be increased in value. EDIT_AMOUNT_UP capability is not available., field=amount_money]]
our scenario is in restaurant, diner needs to make an authorized payment before an order is placed, and he may place another order during his dining and before the first order is paid, and finally he needs to complete the authorized payment with an increased amount of the two orders’ price.
a. use the validation token (SCA) while creating the authorized payment, then the amount can be updated afterwards
b. while making the authorized payment, we only store the token generated from square web sdk by user input, rather than creating a real authorized payment, then at the final payment, we create a complete payment directly with this token.
but we still have a few questions below, may i have your advice please?
in the case of above a. validation token (SCA), according to SCA example Verify the Buyer When Using a Payment Token, we see some user info is required as input, such as address, name, phone, etc., are these info mandatory to generate a validation token? it looks we need user input these on our UI, which is not so convenient to user, although we admit it’ safer for payment
we also hope that just in case user forgets to complete the payment and leave restaurant, the restaurant owner still can charge him with the token; in the case of above b. only storing token from square web sdk, we are also concerning whether user could input an invalid card number on purpose, for apply pay, i believe it should be no problem, as apple pay itself will validate the card info before token generated, but for card payment (rather than digital wallet), can square web sdk also validate the card info while generating token and without an authorized payment created?
Currently UpdatePayment requests are not guaranteed to succeed. For example:
Square might limit the maximum amount a payment can be increased. If an UpdatePayment request exceeds this limit, an AMOUNT_TOO_HIGH error is returned.
If Square chooses to obtain reauthorization, an UpdatePayment request that increases the payment amount might fail. If an UpdatePayment request fails, the unmodified payment can still be completed. If UpdatePayment is not successful, you might consider alternatives to increase the payment. For example:
Complete the unmodified payment amount and ask the customer to pay the additional amount with the same card or new payment method.
Create a new payment with the same card or a new payment method. After the payment is authorized, cancel the original payment.
As for SCA are you passing in the verification_token when calling CreatePayment? If so there’s no further action needed with the verification_token when calling UpdatePayment.
As for SCA are you passing in the verification_token when calling CreatePayment ? If so there’s no further action needed with the verification_token when calling UpdatePayment .
no, currently we didn’t pass in verification_token when calling CreatePayment.
but we are wondering whether UpdatePayment can update the amount if we pass in verification_token in CreatePayment, is it feasible?
(assuming the increased amount doesn’t exceed the maximum amount limit, and the card is from some US bank, and the location is also in US)
If Square chooses to obtain reauthorization, an UpdatePayment request that increases the payment amount might fail.
the case choose to obtain reauthorization is different from exceeding the maximum amount limit in UpdatePayment, right? may i know what would be the condition of this happening?
besides, in the card payment scenario, without creating an authorized payment, square web sdk only can validate the card number format (such as VISA, MASTER, etc.), can’t confirm the card number is valid or not in some bank, is my understanding correct?
we are trying to find a reliable way to confirm some card number existing in bank.
we had a test in sandbox env just now, we added validation token in CreatePayment but it looks not working, the amount still can’t be changed, did we mistake anything?
the info used to generate validation token is as below:
I removed the image that exposed your access token. You’ll want to recycle that access token. Please note that you should never share the access token. They are secret.
The verification_token should be present in the initial CreatePayment request. Then if the payment is able to be updated you’ll get a successful response when calling UpdatePayment. The initial CreatePayment request should alway be as close to the amount that you want to charge. This is because you could authorize an initial amount and then when you call UpdatePayment the amount may exceed the available limit on the card. If you try to first authorize an amount close to the desired charge amount it will increase the likelihood of UpdatePayment succeeding.
You understanding of the Web Payments SDK is correct. It does a light format validation. I you call CreatePayment and get back an authorized payment then that card does exist.
appreciate your kindly remind and action, i was not aware of the access token in curl header in my screenshot
yes, we put verification_token in the initial CreatePayment request, the response is with field capabilities as below
"capabilities": [
"EDIT_DELAY_ACTION"
],
for testing, we passed in amount 68.00 USD in CreatePayment, and amount 78.00 USD in UpdatePayment, but as above capabilities shows, UpdatePayment failed.
Since EDIT_AMOUNT_UP isn’t present in the capabilities you won’t be able to adjust the payment amount. This is the expected result with payments that don’t have EDIT_AMOUNT_UP in the response.
