Overview

A method is identified by its code — qris, va_bca, card. That is the string you send and the string you get back. Every live method works through Direct API and on Kasera Pay Checkout alike.

GET /v1/payment_methods returns this list scoped to your account, with the amount range, the buyer details each method requires, and each method's fee — percent in basis points plus a flat rupiah amount, e.g. {"percent_bps": 70, "flat": 250} for QRIS. Read it rather than hard-coding the codes or the rates — a method can be enabled, suspended or repriced without a release on your side.

What each method needs about the buyer

Nothing about the buyer is required on a create. What a method needs, it needs at payment time — so either you send it in customer, or the checkout page asks the buyer for it.

On Direct API there is no page to ask, so a create naming a method whose required field is missing is rejected 422 with the field named. On Checkout the customer step collects whatever is missing — so it is only an error there if you dropped that step from checkout.steps as well.

Choosing which methods to offer

A create takes payment_methods — an array of codes, the methods this one payment may be paid with. It narrows what the buyer is offered; it can never widen it beyond what your account has enabled.

{
  "amount": 150000,
  "external_id": "ORD-1234",
  "payment_methods": ["va_bca", "va_bri", "qris"]
}

• Omitted — every method enabled on your account is offered.
• One code — that method, no picker. Direct API gets its payment object straight away.
• Several codes — a picker with those, in the order you sent them.

The response reports the outcome in the singular: payment_method is one code, never null — stamped at create with the first code you offered, and updated to the one the buyer actually picks.