Scope note: Hello Clever’s Card APIs are for accepting and managing card payments (create, authorise, capture, void, refund, tokenise) — not for issuing physical/virtual cards to your users. This guide covers the full card acceptance and management lifecycle.

​
What you’ll build

The Card APIs give you end-to-end control of the card payment flow: create a payment, capture authorised funds, void before capture, refund after capture, tokenise cards for repeat use, and reconcile via list/detail endpoints. Webhooks notify you on status changes, and post-purchase flows support upsell scenarios. Accepted schemes include Visa, Mastercard, and other major providers, plus Apple Pay and Google Pay. Funds settle into per-currency float accounts with automatic reconciliation.

​
Choose an integration method

SDK (client-side)

Web/mobile frontend via the Hello Clever JavaScript SDK. Supports USD and AUD. Best for a drop-in checkout without handling raw card data.

Server-to-Server (S2S)

Your backend submits raw card_info. Supports AUD. For PCI DSS–compliant systems wanting full control of auth/capture.
Pick the SDK unless you are PCI DSS–compliant and specifically need raw card handling. The SDK keeps card data off your servers.

​
Prerequisites

  • Merchant account and app-id / secret-key.
  • Sandbox https://api.cleverhub.co; production https://api-merchant.helloclever.co.
  • A webhook endpoint (TLS 1.2, public, commercial cert) for payment status changes.
  • For S2S: a PCI DSS–compliant environment.

​
The card endpoints

​
The payment lifecycle

1

Create (authorise)

Initialise the JS SDK on your frontend, create the payment, and handle the callback. See the SDK Integration guide for setup and initialisation.
This step authorises the payment. Depending on your flow it may auto-capture or leave funds authorised pending capture.
2

Capture or void

  • If the payment was authorised but not captured, call Capture Payment to settle the full amount (e.g. when you ship the order).
  • If you need to cancel before capture, call Void Payment.
Capture and void are mutually exclusive — void only works pre-capture.
3

Refund

After capture, use Refund Payment for a full or partial refund (e.g. returns, price adjustments).
4

Post-purchase / upsell

The Card APIs support post-purchase flows — charge an upsell after the initial purchase, reusing a stored token so the customer doesn’t re-enter card details.

​
Tokenisation and stored cards

Tokenise a card once, then charge it later with Create Payment via Tokenisation using the token_id. When a customer removes a card or you no longer need it, call Delete Token to deactivate it.
Store only the token_id on your side — never raw card data unless you are PCI DSS–compliant and using S2S.

​
Reconciliation

  • List Payment — pull transactions by date range and status for reporting; paginate at 20/page by default.
  • Detail Payment — drill into a single transaction for support and dispute handling.

​
Webhooks

Configure webhook notifications so your system is told when a payment’s status changes (authorised, captured, voided, refunded, etc.). Return 200 OK to every delivery and handle duplicates idempotently; failed deliveries are retried. See the Card Webhook guide for the payload and signature details.

​
Notes

  • Surcharging and digital wallets (Apple Pay / Google Pay) are supported for the card payin service.
  • Match currency support to your integration method: SDK supports USD and AUD; S2S supports AUD.