Non-card Methods — Checkout Form

Besides cards, the Checkout Form shows the non-card methods that are open on your account, such as wallets, mobile billing (Faturana Yansıt) and promissory notes (Senetle Öde). The buyer picks the method in the form, enters the requested data and, depending on the method, approves the payment with a code sent to their phone.

This page is for the Checkout Form path. The Checkout Form SDK makes the non-card method calls (POST /payments/form/payment and the action confirmation) from the buyer's browser itself. You do not need to write any extra code: the code you write is the same as for cards — create an intent on your server and mount the form on your page → Checkout Form.

If you start the payment from your own server, this page is not for you → Payment.

How it works

Enabling methods in the form

• In the panel, on Payments → Form Settings, enable the method group and select the connected provider. The form only shows methods that are enabled and have at least one connected provider.
• The form uses the same list as GET /payments/methods. You can check from your server which methods the form will show with this endpoint.
• To narrow the methods shown for one intent, send settings.paymentMethods on the intent, for example ["card", "mobile_billing"]. This field cannot open a method that is disabled in the panel; it only narrows.
• If you created the intent with "preauth": true, the form only shows methods and providers that support pre-authorization → Pre-authorization.
• If you created the intent with "paymentMethod": "WALLET", the payment is pinned to the wallet: the form opens directly with the wallet and cannot be paid by card or with another method. With walletProvider you can also preselect the wallet.
• If you create the intent with "paymentMethod": "PROMISSORY_NOTE", the payment is pinned to promissory notes. You can provide the due-date schedule in the intent with promissoryNote.schedule; if you do not, the buyer chooses the number of notes → Promissory Notes — With the Checkout Form.

To let the buyer split one order across several methods (e.g. two cards and mobile billing): Split Payments.

Order and providers shown in the form

In the panel, on Payments → Form Settings:

• You drag the method tabs into order. The form shows the tabs in this order.
• In the Payment options list of each non-card method you drag the providers into order. The form shows the options in this order.
• You turn each provider on or off for the form with the Show in the form switch.

Ordering rules:

• If you have not set an order, methods and providers come in the default order; see Listing Methods › Order.
• A provider you connect later is added to the end of its method's order. A provider whose connection you turn off drops out of the order.
• The order is the same in the test and live environments.
• The form, the panel and GET /payments/methods use the same order.

A provider turned off for the form:

• Is hidden only in the form. It stays in the GET /payments/methods list and can be used with POST /payments/direct/payment. To turn a provider off everywhere, turn off its provider connection.
• Cannot be used to start a payment from the form: the request gets 422 payment.provider.disabled_in_form.
• If a method has no provider left that is shown in the form, the method is not shown in the form. A provider under maintenance is not shown in the form either.

Provider choice

In the form the buyer chooses the provider for every non-card method, mobile billing included.

• More than one provider shown in the form: the form lists the options in your order, with each provider's logo and name; the buyer picks one. If there is no logo, the provider's name is shown.
• One provider shown: no picker is shown. The provider's logo (or its name if there is no logo) is visible and the payment is made with that provider.
• The form collects the fields the chosen provider needs and always sends the chosen provider's code.
• The providerSelectionMode of the method row does not change the form's behaviour. It only decides what happens in the Direct API when no providerCode is sent → Listing Methods › Provider selection.

If the choice does not go through:

• If the provider declined the payment before any money moved and the payment record is still open, the buyer can pick another provider or method on the same screen.
• While an attempt whose result is not yet known is in progress, no new choice can be made; the form waits for the result.
• A non-card method can be selected at most 3 times per payment. Once the limit is reached, a non-card selection gets 409 payment.method.selection_attempts_exhausted; the buyer can pay by card.

Steps the buyer sees

Mobile billing

Wallet

Promissory notes

The buyer selects Promissory Notes, sees the schedule you provided or chooses the number of notes, and enters the debtor details (and guarantors if needed). There is no code or redirect: the notes are issued immediately and the form shows the result. Step details: Promissory Notes — What the buyer sees.

Result

• For non-card methods the buyer's browser is not redirected to your callbackUrl; the result is shown in the form. Close the order based on the payment.captured webhook or a GET /payments/:id query.
• If a decline arrived before any money moved and the payment record is still open, the form offers the buyer another provider or method.
• If the payment became FAILED, it cannot be paid again with the same intent; if the buyer wants to pay again, create a new intent.
• If the result is being verified with the provider, the form shows a waiting message; the final result arrives by webhook.

Endpoint reference — POST /payments/form/payment

This section is for reference; the SDK calls the endpoints.

• The amount, basket, buyer and callbackUrl are not in this body; they are read from the intent. If sent, the request gets 400 VALIDATION_ERROR.
• Confirming and resending the code use the action endpoints on Payment; when called from the form, the body carries token (and checkoutSessionProof when needed) instead of a signature.
• The response has the same shape as Payment — Response.

{
  "token": "eyJhbGciOi…",
  "paymentMethod": "MOBILE_BILLING",
  "mobileBilling": { "providerCode": "<providerCode>", "gsmNumber": "+905321234567" },
  "browserFingerprint": "…",
  "paymentChannel": "WEB"
}

Errors

The form shows these errors to the buyer with a clear message. The codes are for support and log analysis.

Code confirmation and resend errors: Payment — Error codes.

Error codes

Webhooks

The data of the events carries paymentMethod (e.g. MOBILE_BILLING, WALLET, PROMISSORY_NOTE) and the providerCode of the provider that processed the payment. The outcomes of promissory notes at maturity arrive as separate events → Promissory Notes — Webhooks. Delivery and signature verification → Webhooks.

Next steps

• Checkout Form — creating the intent and form setting overrides
• Card Payment — 2D and Card Payment — 3D Secure — cards in the form
• Payment — the same methods from the Direct API, the method list and error codes
• Split Payments — letting the buyer pay one order with several cards and methods