Production CreatePayment declined instantly (GENERIC_DECLINE ~65ms), same card approved in Virtual Terminal (AU)

Questions
1

Hi Square team,

We’re an Australian coach business. We built our own booking system using the Web Payments SDK (card form) + Payments API CreatePayment, with our own production application on our own seller account (personal access token). Staff key in cards while the customer is on the phone.

Everything works in sandbox. In production, every payment through our app is declined instantly with GENERIC_DECLINE (PAYMENT_METHOD_ERROR), but the SAME card is approved in our Square Virtual Terminal minutes later.

What we see:

- Decline comes ~65 ms after the payment is created. No risk_evaluation, CVV/AVS NOT_CHECKED, entry_method KEYED, product ECOMMERCE_API.

- The Virtual Terminal payment on the same card: CVV accepted, risk NORMAL, approved in ~700 ms.

- Tried two different cards from two different banks, same result.

Our request:

- source_id from card.tokenize(verificationDetails) with amount, AUD, intent CHARGE, billingContact, customerInitiated true, sellerKeyedIn true

- customer_details { customer_initiated: true, seller_keyed_in: true }

- buyer_email_address, buyer_phone_number, reference_id, note, autocomplete true

- SDK square 46.0.0, Square-Version 2026-09-16

IDs:

- Application: sq0idp-jUBQjOG371aGPRehDhDASg

- Location: LREXZTA8DAPRP (active, AUD, card processing enabled)

- Declined: KMODpBkd3LUSsadYJ6FAd0Z855QZY, iGXuuHEdCfoA3zqSUgISUAaaj6VZY, 4b6rbIsu6icHE4GgW5pTEvatpdEZY

- Approved in Virtual Terminal (same card): Y1lYgKGc6P4ulVkuVdp7zDxB13DZY

Our first tests were small amounts ($1 to $25) a few times in a row, which we now realise may have looked like card testing.

Questions:

1. Is a Square-side risk or security control declining card-not-present payments from our new application? Can it be reviewed and cleared?

2. Is the MOTO flag (seller_keyed_in: true) supported through the Payments API for Australian sellers, or should staff-keyed phone payments leave out customer_details?

Square Seller Support referred us here. Thanks for your help!

4
  1. The corresponding CreatePayment.customer_details values should consistently describe the transaction: customer_initiated: false, seller_keyed_in: true. I would not recommend removing customer_details.
  2. Make sure you are initiating the SDK with the same location_id you are processing transactions for. The location IDs must match between Square.payments(applicationId, locationId) and CreatePayment.location_id.
  3. If you implement the first two and still get errors, reply back with a new payment ID with a timestamp and timezone and I can dig deeper.
5

Thanks! Implemented both: customer_details { customer_initiated: false, seller_keyed_in: true } with matching tokenize values (customerInitiated false, sellerKeyedIn true), and confirmed Square.payments() and CreatePayment both use LREXZTA8DAPRP.

Two new tests, both $72.00 AUD, both still GENERIC_DECLINE:

  1. 8JcdvDwt1zuf8qaG8VWBg3GK9eDZY: 17 Oct 2026, 11:56:45 pm AEST (13:56:45 UTC). Visa Debit, CVV ACCEPTED, about 1 s, so it seems to reach the issuer now.
  2. KWThOqZbhdSFI6JLCR0pykTJT4PZY: 18 Oct 2026, 12:03:48 am AEST (14:03:48 UTC). Mastercard Debit, CVV NOT_CHECKED, declined instantly. This same card is approved in our Virtual Terminal (payment Y1lYgKGc6P4ulVkuVdp7zDxB13DZY).

Could you check whether a Square-side risk control is declining these, possibly flagged from our earlier test declines, and whether it can be cleared?