The token obtained from Oauth cannot create customer card

Questions
1

Hi,

We want to create card for our customer by below API and it was succeeded with the Application Access Token. However, if we pass the token obtained from Oauth procedure, it would return 400 error. Please help to figure out the root issue.

curl https://connect.squareup.com/v2/cards \
  -X POST \
  -H 'Square-Version: 2023-12-13' \
  -H 'Authorization: Bearer token' \
  -H 'Content-Type: application/json' \
  -d '{
    "idempotency_key": "9f140950-1310-4587-98de-556b7f9181c0",
    "card": {
      "billing_address": {
        "postal_code": "60616"
      },
      "customer_id": "899f74ef-2e23-4413-a5f9-9c4ee0906f5a"
    },
    "source_id": "cnon:CBESEK8K2-fake-source-id"
  }'

{
  "errors": [
    {
      "category": "INVALID_REQUEST_ERROR",
      "code": "INVALID_CARD_DATA",
      "detail": "Invalid card data.",
      "field": "source_id"
    }
  ]
}

Note: For the safety, I provide the fake ids instead of real source id and bearer token, you can check the API log on this application: sq0idp-4M6ZTXS5LE0N7qOV163dgg. Please let me know if you want to check the details.

2

Hi @wsdzy2010 ,

There are a few thing you will want to double check:

  • If you are in production, you need to use a real card. The sandbox test cards will only work if you are using sandbox API credentials. Given you are testing OAuth, I assume you’re in production. You will need to use a real card. You cannot make up a source_id like in your example.
  • Payment tokens are a one time, time limited use. Make sure you are using a fresh payment token in as your source.
  • Try testing a GET API call, to double check OAuth access. I would suggest ListLocations.
  • There is a chance the card information was mis-inputted. Try re-entering in the card.

Give these suggestions a try, and let me know if that gets your a successful 200 card on file.

3

Hi,

Thanks for the reply. I read the whole checklist and here is the results:

  1. We are using the real card to make up the source_id in production env. In my previous comment’s note, I provided a fake id just because this is a public area, and I thought you can find the API call by the real idempotency_key. If you need the source id that hasn’t been consumed to check, please let me know.

  2. Yeah, I used the the fresh idempotency_key and source id.

  3. The GET API call works for both tokens.

  4. The card information is the same for both token tests, but only the API call with access token succeeded.

4

Thanks for trying my suggestions.

Only other suggestion is to double check that you are using the same application id when you tokenize the card with Web Payments SDK as is associated with the respective access token. If you are using OAuth, I do not expect this to be an issue, since I assume you are using the same application id for both your personal access token and OAuth token that you got from the merchant when you provided the Authorization URL with the application id as client id.

In that case, I think your implementation sounds solid, and there is nothing more you can do as the developer. Proof of concept, worked with your access token, but not the OAuth access token.

That error actually comes from the customer’s card issuer (typically a bank). In these cases, Square attempted to save the card on file, but was told by the bank that they are not accepting the payment. Unfortunately, banks do not always provide detailed information about why the card on file attempt did not work.

This can happen for any number of reasons. Square recommends that you handle this error by prompting your customers to retry entering their payment information (you’ve noted it already worked with your access token, but not the OAuth access token), then contact their bank if the error persists.

Maybe have the merchant double check if they’re fully setup in the Seller Dashboard to start taking payments with Square.