> ## Documentation Index > Fetch the complete documentation index at: https://docs.singapay.id/llms.txt > Use this file to discover all available pages before exploring further. # Charge > Pulls funds from a bound bank account into the merchant settlement account. ## OpenAPI ````yaml https://payment-b2b.singapay.id/api/docs/merchant-api.json post /api/v2.0/direct-debit/charge openapi: 3.1.0 info: title: Singa Merchant API description: >- OpenAPI specification for the merchant/partner HTTP API. All routes below are additionally protected by `ip.whitelisted.merchant` — the caller IP must be registered for the credential or merchant. Obtain a JWT using `POST /api/v1.0/access-token/b2b` (Basic auth) or `POST /api/v1.1/access-token/b2b` (X-Signature) before calling secured endpoints. version: 1.0.0 servers: - url: https://sandbox-payment-b2b.singapay.id description: >- API host. Paths include `/api` prefix (see `RouteServiceProvider`). Replace scheme/host with your environment. security: [] tags: - name: Security description: >- Merchant authentication (`OauthMerchantTokenController`). **v1.1** B2B token uses `X-CLIENT-ID`, `X-PARTNER-ID`, and `X-Signature` (no Basic auth). Secured routes also require the issued Bearer JWT plus `X-PARTNER-ID`. - name: Accounts description: >- Account management (`routes/merchantApiRoute.php`, `v1.0`). Path parameter `{id}` is always the account ULID. - name: Balance Inquiry description: >- Merchant and per-account balance inquiry (`BalanceController`, `v1.0`). Path `account_id` is the account ULID. - name: Statements description: >- Per-account statement list and detail (`AccountController::accountStatements`, `accountStatementDetail`, prefix `v1.0/statements`). Flugger responses; detail path param `{statement_id}` maps to `statements.transaction_id`. - name: Payment Link description: >- Payment link CRUD and payment-method catalog (`PaymentLinkApiController`, prefix `v1.0/payment-link-manage`). `account_id` is ULID; `payment_link_id` is numeric `payment_links.id`. - name: Payment Link History description: >- Payment link transaction/history listing and detail (`PaymentLinkApiController`, prefix `v1.0/payment-link-histories`). `history_id` is numeric `payment_link_histories.id`. - name: Virtual Account description: >- Native VA CRUD (`VirtualAccountController`, prefix `v1.0/virtual-accounts`). `account_id` and `virtual_account_id` are ULIDs. - name: VA Transaction description: >- VA money-in transaction listing and detail (`VirtualAccountController`, prefix `v1.0/va-transactions`). - name: QRIS (Money In) description: >- MPM dynamic QRIS list, show, and generate (`QrisMpmDynamicApiController`, prefix `v1.0/qris-dynamic`). - name: QRIS (Money Out) description: >- Issuer MPM decode/inquiry, payment credit (money out), and transaction status (`QrisIssuerMpmController`, `QrisApiV2Controller::checkStatus`, prefix `v2.0/qris`). Related list/detail: `GET /api/v2.0/qris/transaction/...`. - name: E-Wallet (Money In) description: >- E-Wallet Native checkout and transactions (`EwalletNativeApiController`, `EwalletNativeTransactionApiController`, `EwalletNativeV2ApiController`). Paths include `v1.0/ewallet-native`, `v1.0/ewallet-native-transactions`, and `v2.0/ewallet-native`. - name: E-Wallet (Money Out) description: >- E-wallet disbursement / top-up to beneficiary wallets (`EWalletTopUpController`, prefix `v2.0/ewallet`). Responses use the custom **`MerchantV2ApiEnvelope`** with **`MerchantV2ResponseCode`** (SP000–SP020). - name: Card (Money In) description: >- One-time card payment, cancel, and inquiry (`CardPaymentMerchantApiController`, prefix `v2.0/card`). - name: Subscription (Recurring) description: >- Credit-card recurring subscription plans (`SubscriptionPlanApiController`, prefix `v2.0/recurring`). Plan `{id}` is UUID (`sub_plans.id`). - name: Direct Debit description: >- Direct Debit — bind a customer bank account once via hosted webview, then charge it host-to-host (`DirectDebitMerchantController`, prefix `v2.0/direct-debit`). Binding `{binding_id}` and transaction `{transaction_id}` are UUIDs. Responses use the **`MerchantV2ApiEnvelope`** with both standard SP000–SP020 codes and Direct-Debit-specific codes (`SP_DD_*`). The `/charge` endpoint is additionally protected by **`X-Signature`** + **`X-Timestamp`** (`verify.signature-internal`); see operation parameters for the signing scheme. - name: Account Transfer description: >- Move funds between sub-accounts within the same merchant (`AnotherAccountApiController`, prefix `v1.0/account-transfer`). The transfer endpoint requires request signature headers (`verify.signature-internal`). Both accounts must belong to the authenticated merchant and be accessible to the credential. - name: Disbursement (Money Out) description: >- Bank disbursement (`DisbursementController` **v1.0**, `DisbursementV2Controller` **v2.0**). **v1.0** list/show/fee/beneficiary/transfer use Flugg envelopes; v1 inquiry-status uses the **custom v2 envelope** (`MerchantV2ApiEnvelope`, codes **SP000–SP020**). **v2.0** check-beneficiary, transfer, and inquiry-status use the same custom envelope — see component schema **`MerchantV2ResponseCode`** for the full response code table. - name: Cardless Withdrawal description: >- Cardless withdrawal API for initiating ATM cash withdrawals without a physical card. Supports creating withdrawals with OTP generation, listing transaction history, viewing transaction details, canceling pending withdrawals, and deleting canceled records. All endpoints use the `v1.0/cardless-withdrawals` route prefix and the standard success/error response envelope. Path parameter `{id}` refers to the `transaction_id` (platform-assigned business identifier). paths: /api/v2.0/direct-debit/charge: post: tags: - Direct Debit summary: Charge description: >- Pulls funds from a bound bank account into the merchant settlement account. operationId: directDebitCharge parameters: - name: X-Signature in: header description: >- HMAC-SHA512 hex signature, computed as `HMAC_SHA512(clientSecret, "{HTTP_METHOD}:{REQUEST_URI}:{ACCESS_TOKEN}:{SHA256_HEX(MINIFIED_BODY)}:{X_TIMESTAMP}")`. `MINIFIED_BODY` is the request body with object keys recursively sorted alphabetically and re-serialised with no whitespace (an empty/missing body hashes the empty string). `ACCESS_TOKEN` is the bearer token without the `Bearer ` prefix. Signature mismatch returns **401** with `response_code=4019900`. required: true schema: type: string - name: X-Timestamp in: header description: >- ISO-8601 timestamp of the request; used as part of the signed string and rejected by the gateway if more than ±5 minutes off the server clock. required: true schema: type: string format: date-time requestBody: required: true content: application/json: schema: $ref: '#/components/schemas/DirectDebitChargeRequest' responses: '200': description: >- **SP000** Charge accepted. `data` matches `DirectDebitTransactionData`; `status=PENDING` (await settlement webhook) or `status=FAILED` if the upstream rejected immediately. `fees` are present only on a later `SUCCESS`. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP000 response_message: Charge accepted data: transaction_id: 7c2e1a4b-9d6f-4e3a-8b1c-2d4f9a1c5b3e binding_id: 9a1c5b3e-2d4f-4d8c-93cf-9a1c5b3e2d4f account_id: 01HZX9JK4M5N6P7Q8R9STUVWXY merchant_reference: INV-2026-0001 amount: 150000 currency: IDR description: Subscription June 2026 status: PENDING requires_otp: false paid_at: null failure_code: null failure_reason: null web_redirect_url: null created_at: '2026-06-04T08:30:01+07:00' updated_at: '2026-06-04T08:30:01+07:00' '202': description: >- **SP000** OTP required — `data.status=PENDING_OTP` and `data.requires_otp=true`. Collect the OTP from the customer and call `POST /verify-otp` with the same `transaction_id`. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP000 response_message: OTP required to complete charge data: transaction_id: 7c2e1a4b-9d6f-4e3a-8b1c-2d4f9a1c5b3e binding_id: 9a1c5b3e-2d4f-4d8c-93cf-9a1c5b3e2d4f account_id: 01HZX9JK4M5N6P7Q8R9STUVWXY merchant_reference: INV-2026-0001 amount: 150000 currency: IDR description: Subscription June 2026 status: PENDING_OTP requires_otp: true paid_at: null failure_code: null failure_reason: null web_redirect_url: null created_at: '2026-06-04T08:30:01+07:00' updated_at: '2026-06-04T08:30:01+07:00' '401': description: >- Unauthorized — bad bearer token, missing `X-PARTNER-ID`, or `X-Signature`/`X-Timestamp` mismatch (numeric `4019900` from `verify.signature-internal`). content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: '4019900' response_message: Signature verification failed data: null '403': description: >- **SP403** Authenticated user has no access to that account, OR IP not on the merchant allowlist. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP403 response_message: Access denied to this account data: null '404': description: >- **SP020** Merchant Account Not Found (`account_id` not owned by merchant), or **SP_DD_NOT_FOUND** (`binding_id` not owned by merchant). content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP020 response_message: Account not found data: null '409': description: >- **SP_DD_DUPLICATE_REFERENCE** — `merchant_reference` already used; `data.transaction_id` carries the original. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP_DD_DUPLICATE_REFERENCE response_message: Duplicate merchant reference data: transaction_id: 7c2e1a4b-9d6f-4e3a-8b1c-2d4f9a1c5b3e '422': description: >- **SP018** Validation error, OR **SP_DD_BINDING_NOT_ACTIVE** — binding exists but its current status is `PENDING_AUTH` / `FAILED` / `UNBOUND` / `EXPIRED`. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP_DD_BINDING_NOT_ACTIVE response_message: Binding is not active data: null '502': description: >- **SP_DD_CHARGE_FAILED** — upstream gateway call could not be persisted. Merchant action: poll `GET /transactions/{transaction_id}` (the row may still have been created) before retrying with the same `merchant_reference`. content: application/json: schema: $ref: '#/components/schemas/MerchantV2ApiEnvelope' example: response_code: SP_DD_CHARGE_FAILED response_message: Failed to process charge. Please retry or check status. data: null security: - BearerAuth: [] PartnerId: [] components: schemas: DirectDebitChargeRequest: description: >- Pulls funds from an active binding into the merchant settlement account identified by `account_id`. The binding must be `ACTIVE`. `merchant_reference` is an idempotency key; replaying the same value returns **409 SP_DD_DUPLICATE_REFERENCE** with the original `transaction_id` in `data`. required: - account_id - binding_id - merchant_reference - amount properties: account_id: description: >- ULID of the merchant settlement account that should receive the funds. Must be owned by the authenticated merchant; access policy on the account is also enforced. type: string example: 01HZX9JK4M5N6P7Q8R9STUVWXY binding_id: description: UUID of an `ACTIVE` `DirectDebitBinding` owned by the merchant. type: string format: uuid example: 01HZX9JK4M5N6P7Q8R9STUVWXY merchant_reference: description: Merchant-side unique idempotency key for this charge. type: string maxLength: 100 example: ref-123456 amount: description: Amount to debit, in the unit of `currency`. Minimum `1` IDR. type: number minimum: 1 example: 10000 currency: description: >- ISO-4217. Defaults to `IDR` (the only value supported by Direct Debit). type: - string - 'null' maxLength: 3 minLength: 3 example: IDR description: description: >- Customer-facing description for this charge. This value is stored with the transaction and may appear in reports. type: - string - 'null' maxLength: 512 example: Description of the charge type: object MerchantV2ApiEnvelope: description: >- SingaPay Merchant API v2 custom response envelope (`ApiResponderHelper::responseJson`, `ApiResponseTrait`). Business outcome is determined by `response_code` (SP000–SP020), not by HTTP status alone. On success (`SP000`), `data` holds the operation payload. On errors, `data` often includes a `message` and may echo request fields. required: - response_code - response_message properties: response_code: $ref: '#/components/schemas/MerchantV2ResponseCode' response_message: $ref: '#/components/schemas/MerchantV2ResponseMessage' data: description: >- Endpoint-specific payload on success, or error context (validation message, inquiry result with `status` invalid, etc.). type: - object - 'null' additionalProperties: true type: object example: response_code: SP000 response_message: Successfully data: [] MerchantV2ResponseCode: description: SingaPay custom business response code. type: string example: SP000 MerchantV2ResponseMessage: description: Human-readable label paired with `response_code`. type: string example: Successfully securitySchemes: BearerAuth: type: http description: >- JWT issued by `POST /api/v1.1/access-token/b2b`. Send `Authorization: Bearer `. bearerFormat: JWT scheme: bearer PartnerId: type: apiKey description: Merchant API key (`Credential.api_key`). Required on every request. name: X-PARTNER-ID in: header ````