Card

You start a card payment from your own server with POST /payments/direct/payment and paymentMethod: "CARD". The endpoint uses the same request and response shape as wallet and mobile billing. This page covers choosing between 2D and 3D Secure and the rules that apply to every card payment; request fields, examples and errors are on Card — 2D and Card — 3D Secure.

If you use the Checkout Form, the form charges the card → 2D Form · 3D Form.

⚠️

PCI DSS required. You receive and send the full card number (PAN) on your server, which puts your systems in PCI DSS scope (SAQ D). Unless you are certified to handle card data, use the Checkout Form. Charging a previously saved card needs no PAN; see Saved cards.

2D or 3D Secure

	2D	3D Secure
Request	`force3D` omitted or `false`	`force3D: true`
Bank authentication	None	The buyer confirms the transaction with their bank (SMS code, banking app, biometrics)
Redirecting the buyer	None; the result comes back in the same response	The response carries a `REDIRECT` action; the buyer's browser goes to the bank page and returns to your `callbackUrl`
Liability shift	None; pair it with your own risk controls	Yes
Saving the card	Not possible	Done during the payment
Suited for	Saved-card charges, server-side billing, flows where a redirect is not possible	Payments taken while the buyer is present, saving cards
Page	Card — 2D	Card — 3D Secure

force3D is sent only with paymentMethod: "CARD" and must be a boolean; a string such as "true" gets 400 VALIDATION_ERROR.
The 3D Secure decision is your force3D choice. The 3D settings defined for the Checkout Form (force3D on the intent, settings.threeD and the panel 3D policy) do not apply to card payments started from your server.
The risk evaluation or a limit rule on your account can turn a 2D request into 3D Secure; see Card — 2D › Turning into 3D.

Saved cards

Saving: A card is saved only during a payment made with 3D Secure; there is no separate "save card" call. Send customerId and card.cardSave: true together with force3D: true. On a 2D request cardSave: true gets 400 payment.card.save_requires_3ds before the payment starts. Details: Card — 3D Secure › Saving a card.
Charging: There is no separate saved-card endpoint. Put cardUserKey and cardToken into the card object instead of the raw card fields; this is the same for 2D and 3D Secure requests.
cardToken is the permanent reference returned when the card was saved (storedCardToken). The Checkout Form's single-use card token cannot be used.
Enabling card storage and listing cards: Stored Cards.

Card rules

Amount: All amounts are minor-unit integers: "amount": 10050 means ₺100,50. The amount is sent only in amount and is the basket total.
Card fields: card, force3D, installment and installmentQuoteToken can only be sent with paymentMethod: "CARD".
Installments: When installment is 2 or more, the installmentQuoteToken from the installment quote is required. The system computes the installment fee from the quote and adds it to the charged amount: charged amount = amount + installment fee.
Provider: For card, routing chooses the provider; the card block has no providerCode. In the method list the card row carries providerSelectionMode: "PLATFORM" and providerSelection: "ROUTED"; see Listing Methods.
Idempotency: Idempotency-Key is required; send a new key to retry a declined order.
Pre-authorization: With "preauth": true the amount is held and the payment becomes AUTHORIZED. The instruction is never turned into an immediate charge; see Pre-authorization, Capture & Void.
Final result: Fulfil the order on the payment.captured webhook or a GET /payments/:id check. Do not open a new charge on a 202 response.

Endpoint, authentication, actions and the common error codes: Payment.

Pages

Card — 2D→Card — 3D Secure→

Listing Methods 2D