CreateCard INVALID_CARD_DATA with Ecuador-issued international Visa after successful payment

Questions
1

Hello Square Developer Team,

I’m experiencing a consistent issue specifically when trying to save an international Visa credit card issued in Ecuador as a Card on File.

The important point is that Square successfully processes and captures the payment with this Ecuador-issued card, but CreateCard fails immediately afterward.

I’m following the documented flow:

Web Payments SDK → CreatePayment → payment_id → CreateCard

The Web Payments SDK tokenization and payment are successful:

  • Card country: Ecuador (EC)

  • Card type: Visa Credit

  • Payment status: COMPLETED

  • Card details status: CAPTURED

  • Entry method: KEYED

  • CVV status: CVV_ACCEPTED

  • AVS status: AVS_NOT_CHECKED

  • Risk level: NORMAL

After the successful payment, I immediately call:

CreateCard(source_id = payment_id, card.customer_id = customer_id)

However, CreateCard returns:

category: INVALID_REQUEST_ERROR
code: INVALID_CARD_DATA
detail: Invalid card data.
field: source_id

Example Payment ID:

PdFdgwzKEgQRqrVIWXCPSiTvAtBZY

Customer ID:

XN7A5KX09KMWZM98ZT6PPZ9ZKW

Location ID:

42863CWXB158P

I have tested the same Ecuador-issued card both with the Ecuador billing postal code included and with the postal code completely omitted. The payment succeeds in both cases, but CreateCard still fails.

I also previously tested the alternative flow using a Web Payments SDK token with STORE and calling CreateCard directly. Cards issued in Ecuador also failed at the CreateCard step.

So the consistent behavior I’m seeing is:

Ecuador-issued Visa → Payment succeeds → CreateCard fails

Could you please clarify:

  1. Is using a successful payment_id as the source_id for CreateCard still the correct and supported method?

  2. Are there any known restrictions or additional requirements for creating Cards on File from international cards issued in Ecuador?

  3. Since CreateCard performs a $0 verification, can you check whether the $0 verification for the Payment ID above was actually submitted to the Visa network / Ecuadorian card issuer?

  4. If it reached the issuer, was the verification declined? Is there an internal issuer/network response code behind the INVALID_CARD_DATA error?

  5. Could the AVS_NOT_CHECKED result be relevant when attempting to store an Ecuador-issued card?

The card itself is valid and Square successfully captures the payment. The problem occurs specifically when attempting to create the Card on File.

Thank you.

This is the payment:

{
“payment”: {
“id”: “PdFdgwzKEgQRqrVIWXCPSiTvAtBZY”,
“created_at”: “2026-09-18T03:58:12.747Z”,
“updated_at”: “2026-09-18T03:58:13.502Z”,
“amount_money”: {
“amount”: 658,
“currency”: “USD”
},
“status”: “COMPLETED”,
“delay_duration”: “PT168H”,
“source_type”: “CARD”,
“card_details”: {
“status”: “CAPTURED”,
“card”: {
“card_brand”: “VISA”,
“last_4”: “[redacted]”,
“exp_month”: 7,
“exp_year”: 2030,
“fingerprint”: “[redacted]”,
“card_type”: “CREDIT”,
“prepaid_type”: “NOT_PREPAID”,
“bin”: “[redacted]”,
“payment_account_reference”: “[redacted]”
},
“entry_method”: “KEYED”,
“cvv_status”: “CVV_ACCEPTED”,
“avs_status”: “AVS_NOT_CHECKED”,
“auth_result_code”: “114266”,
“statement_description”: “SQ *CARS4GO CAR RENTAL I”,
“card_payment_timeline”: {
“authorized_at”: “2026-09-18T03:58:13.051Z”,
“captured_at”: “2026-09-18T03:58:13.502Z”
}
},
“location_id”: “42863CWXB158P”,
“order_id”: “QMWpXD6PSHFM6afCOFqRqWQ8mDWZY”,
“risk_evaluation”: {
“created_at”: “2026-09-18T03:58:13.362Z”,
“risk_level”: “NORMAL”
},
“buyer_email_address”: “[redacted]”,
“billing_address”: {
“address_line_1”: “[redacted]”,
“locality”: “[redacted]”,
“country”: “EC”,
“first_name”: “[redacted]”,
“last_name”: “[redacted]”
},
“note”: “Cars4Go Payment from link”,
“customer_id”: “XN7A5KX09KMWZM98ZT6PPZ9ZKW”,
“total_money”: {
“amount”: 658,
“currency”: “USD”
},
“approved_money”: {
“amount”: 658,
“currency”: “USD”
},
“receipt_number”: “PdFd”,
“receipt_url”: " [redacted] ",
“delay_action”: “CANCEL”,
“delayed_until”: “2026-09-25T03:58:12.747Z”,
“application_details”: {
“square_product”: “ECOMMERCE_API”,
“application_id”: “sq0idp-6B4qzJJ9-Pj8dbsoihZsYQ”
},
“version_token”: “DRNaLHsv0O6AtBD5wH3P1m5Hw29JBUyo3JyU8JzzA6F6o”
}
}

this is the card request:

{
“idempotency_key”: “savecard_6aacb6d5c8bd70.41884493”,
“source_id”: “[redacted]”,
“card”: {
“cardholder_name”: “[redacted]”,
“customer_id”: “XN7A5KX09KMWZM98ZT6PPZ9ZKW”
}
}

this is the card response:

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

Thank you.

3

Thanks for sharing the details. I was able to confirm that the payment was approved and captured successfully, and the following CreateCard request returned INVALID_CARD_DATA for source_id.

Using a successful payment_id as the source_id for CreateCard is a supported flow. However, a card being accepted for a payment does not always mean it can be saved as a Card on File. INVALID_CARD_DATA is a generic error for the storage step, and the API does not return a more specific underlying reason.

I’m not aware of any Ecuador-specific API restriction from this request, and AVS_NOT_CHECKED by itself would not explain the result. I also cannot confirm through whether a separate verification was sent to the issuer or provide an issuer/network response for the failed save attempt.

One thing to double-check in the Web Payments SDK flow:

For keyed card-not-present payments, pass verificationDetails into card.tokenize() so the token includes any required 3DS authentication. The amount and currency in verificationDetails must match the CreatePayment request. In this specific payment, 3DS was completed successfully, so it does not appear to be the reason this CreateCard call failed. It is still worth including for future payment or direct-store attempts.

Since you are seeing the same result with both the payment-ID and direct-store flows, your overall integration approach looks correct. The next best test is another eligible card, or checking with the issuer about Card-on-File/credential-storage support.

5

Hello Square Developer Support,

Att: zacstlouis.

We are investigating a reproducible issue when attempting to store certain international Visa cards on file using the Square Web Payments SDK and Cards API.

We have isolated the issue and tested both the legacy buyer-verification flow and the current Web Payments SDK STORE tokenization flow.

Our merchant is located in the United States. The affected card is a Visa credit card issued in Ecuador.

Current isolated test

We created a completely separate test containing no payment operation.

There is no CreatePayment call and no charge to the customer.

The test follows this flow:

  1. Initialize the Web Payments SDK card object.

  2. Call card.tokenize(verificationDetails) with:

{
    intent: "STORE",
    billingContact: {
        // cardholder billing information
        countryCode: "EC",
        // address, city, state, name, email and phone supplied
    },
    customerInitiated: true,
    sellerKeyedIn: false
}

  1. Tokenization succeeds.

  2. No 3DS challenge is presented to the cardholder.

  3. The resulting payment token is sent as source_id to CreateCard.

  4. CreateCard is rejected with:

{
  "errors": [
    {
      "category": "PAYMENT_METHOD_ERROR",
      "code": "CARD_DECLINED_VERIFICATION_REQUIRED",
      "detail": "Card declined. A verification is required to process this payment."
    }
  ]
}

This is the behavior we would like Square to investigate.

According to the Web Payments SDK documentation, when verificationDetails are supplied to card.tokenize(), Square automatically determines whether authentication is required during tokenization and displays an authentication challenge if one is needed.

In our test, tokenization succeeds without presenting a challenge, but the immediately following CreateCard operation determines that verification is required.

Same result with legacy verification flow

We also reproduced the issue using the older explicit STORE verification flow:

TOKENIZE_STORE_RETURNED
status: OK
card_brand: VISA
card_type: CREDIT
country: EC
postal_code_present: false
intent: STORE

VERIFY_BUYER_STORE_RETURNED
status: OK
intent: STORE
user_challenged: false

CUSTOMER_LOOKUP_RESULT
status: SUCCESS

CREATE_CARD_REQUEST
source_token_present: true
verification_token_present: true
customer_id_present: true
country: EC

CREATE_CARD
result: FAILED

Square then returned:

{
  "category": "PAYMENT_METHOD_ERROR",
  "code": "CARD_DECLINED_VERIFICATION_REQUIRED",
  "detail": "Card declined. A verification is required to process this payment."
}

Therefore, in the legacy test:

  • verifyBuyer(STORE) returned successfully.

  • A verification token was generated.

  • No challenge was presented (user_challenged: false).

  • The verification token was supplied to CreateCard.

  • CreateCard nevertheless returned CARD_DECLINED_VERIFICATION_REQUIRED.

Important comparison with another Ecuador-issued Visa

We have successfully stored another Ecuador-issued Visa card through Square.

In that successful case, the cardholder was presented with 3DS authentication/verification codes, completed the authentication, and the card was successfully stored on file.

Therefore, this does not appear to be a general inability to store Ecuador-issued Visa cards.

The relevant difference we are observing is:

Successful Ecuador Visa:

3DS challenge presented
→ Cardholder completes verification
→ CreateCard succeeds


Affected Ecuador Visa:

STORE tokenization/verification succeeds
→ No 3DS challenge is presented
→ CreateCard returns
  CARD_DECLINED_VERIFICATION_REQUIRED

Additional troubleshooting already performed

We previously investigated the billing postal code.

For the affected Ecuador Visa, we tested without sending a postal code. The Web Payments SDK successfully tokenizes the card, and our application now allows the request to reach Square’s CreateCard endpoint.

The current CARD_DECLINED_VERIFICATION_REQUIRED response is therefore the actual response received from Square’s Cards API, not an application-side billing-address validation error.

We also confirmed:

Card brand: VISA
Card type: CREDIT
Prepaid: NOT_PREPAID
Country: EC
STORE tokenization: SUCCESS
Buyer verification: SUCCESS in legacy test
user_challenged: false
Customer lookup: SUCCESS
CreateCard request reaches Square: YES
CreateCard result: CARD_DECLINED_VERIFICATION_REQUIRED

Question for Square Engineering

Could you please investigate why Web Payments SDK STORE tokenization does not trigger a 3DS challenge for this card when the immediately following CreateCard request determines that additional verification is required?

Specifically, we would like to understand:

  1. Why does card.tokenize() with intent: "STORE" return a successful token without presenting a 3DS challenge, while CreateCard subsequently returns CARD_DECLINED_VERIFICATION_REQUIRED?

  2. Is the issuer requesting step-up authentication during the $0 card verification performed by CreateCard?

  3. If so, how should our Web Payments SDK integration trigger or satisfy that additional authentication requirement before calling CreateCard?

  4. Is there any additional information from the tokenization or Cards API response that we should capture to diagnose why the authentication remains frictionless during tokenization?

  5. Since another Ecuador-issued Visa successfully triggers 3DS and can be stored, could this behavior be specific to the issuer/card authentication configuration rather than our integration?

We can provide the relevant Square request IDs, customer ID, timestamps, application ID, location ID, and additional API logs privately if needed.

For security reasons, we have intentionally omitted the full PAN, CVV, payment tokens, verification tokens, and card-on-file IDs from this report.

Thank you.

6

Could you please DM me the following for the test that returned CreateCard result: CARD_DECLINED_VERIFICATION_REQUIRED

  1. Square request id (found in the response header)
  2. application id
  3. customer id
  4. timestamp + timezone

Could you also verify if both Ecuador-issued Visas are issued by the same or different banks?

7

Hello, sure how can i do that?

8

Can you please tell me where do I have to find the Squere request ID? Thank you.

FRANK CEDENO

9

It may be difficult to get the request id post mortem, a timestamp is sufficient and if you have an idempotency key that helps even more!

10

Hello, I already send you all info by DM, if you haven’t received let me know