Adyen 14_006 - paymentMethod object has not been provided in the request

TL;DR: Your /payments request is missing the entire paymentMethod object. Always include it with the type the shopper selected, plus the fields that type needs, and log the raw JSON to confirm it is sent.

The exact error:

14_006 - paymentMethod object has not been provided in the request

The fix

1. Log the full JSON body of the /payments request your server sends. Expected: You can see whether paymentMethod is present in the actual HTTP body.

2. Add the paymentMethod object with type set to the shopper's selected method on every code path. Expected: The request always carries how the shopper is paying.

3. Include the type-specific fields (encrypted card data for scheme, issuer for redirect methods) and resubmit. Expected: Adyen moves past validation to authorization or a further action.

When this applies

• /payments returns 14_006
• A new checkout code path was just deployed
• The frontend posts the order but the method selection never reaches your server

When it does NOT apply

• paymentMethod is present but missing fields (that is 14_004)
• The details inside are malformed (that is 14005 or 14007)
• /payments/details calls, which use a different request shape

Versions

Adyen Checkout API v68 through v71.

Why it happens

Adyen routes the payment based on paymentMethod.type. With the whole object missing there is nothing to route, so validation rejects the request with 14_006 before any further checks.

Edge cases and pitfalls

• Some SDK wrappers nest the object under a different key; check the serialized JSON, not the builder code
• A redirect payment method still needs paymentMethod with type and returnUrl, not just the amount
• The /sessions flow builds paymentMethod from the shopper's selection automatically

This is the simplest of the paymentMethod errors: the field is absent, not malformed. Adyen requires every /payments call to say how the shopper is paying via the paymentMethod object with at least a type. The usual cause is request-building code that only adds paymentMethod conditionally and skips it on some path, or a frontend that posts the amount and reference but forgets the shopper's selected method. The fix is to always include paymentMethod with the type the shopper chose, plus the type-specific fields. For cards that means type scheme plus the encrypted card fields; for redirect methods like iDEAL it means type plus issuer. Log the exact JSON you send and confirm the paymentMethod key exists at the top level of the request.