Skip to main content

​
Payments Overview

Zentra’s current public payment surface is built around charge creation, verification, refunds, and stored payment tokens.

​
Overview

  • POST /api/v1/payments/charges
  • GET /api/v1/payments/charges
  • GET /api/v1/payments/charges/:reference
  • POST /api/v1/payments/charges/:reference/verify
  • POST /api/v1/payments/refunds
  • GET /api/v1/payments/refunds/:reference
  • POST /api/v1/payments/tokens/card
  • POST /api/v1/payments/tokens/bank-account
  • GET /api/v1/payments/customers/:customer_id/tokens
Amounts must be sent in minor units, requests should be idempotent, and recurring flows should reuse saved payment tokens instead of storing raw card data in your own app.

​
Payment Modes

  • customer_action_required: create a customer-present charge that the user completes
  • merchant_initiated: create a recurring or follow-on charge using a primed saved payment token

​
Recurring Flow

  1. tokenize the payment method
  2. create a setup charge with capture_mode: customer_action_required
  3. verify the successful charge so the reusable provider authorization can be bound to the token
  4. create later renewals with the same payment_token_id and capture_mode: merchant_initiated
Older hosted-checkout wording in some draft pages is being replaced by this charge and token contract. Treat this page plus the changelog as the reviewed payment source of truth for now.

Create Charge

Create a customer-present or recurring charge

Verify Charge

Confirm charge outcome and bind recurring reuse

Refunds

Return funds for a previous successful charge

Guide

End-to-end payment and recurring integration flow