Charges

A charge represents an attempt to collect money from a customer. Charges always go through Lidya's hosted checkout — card data never touches your servers.

States

pending → succeeded
        ↘ failed
        ↘ expired
        ↘ canceled
        → refunded   (terminal, after succeeded)

State	Meaning
`pending`	Created. Customer has not yet completed payment.
`succeeded`	Funds confirmed by the acquirer. Net amount in pending balance.
`failed`	Customer attempted, payment was declined.
`expired`	Customer never completed within the window (default 30 min).
`canceled`	You called the cancel endpoint before customer paid.
`refunded`	We've reversed the funds. Net deducted from available.

Fees

We deduct our card fee at the moment a charge moves to succeeded. The default tier is 17.50% (feeTierCardBps: 1750). The deducted fee shows up as a fee_debit LedgerEntry alongside the deposit_credit for the gross amount.

What we don't do

We don't store card data — ever. Charges go through Balupay's hosted page, which is PCI DSS Level 1 audited.
We don't run 3DS challenges in your browser. The acquirer handles that.
We don't charge merchants for failed attempts.

Test vs live behaviour

In sandbox (sk_test_* keys), Balupay's test environment auto-completes some charges and forces failure on others based on canned card numbers documented in their merchant panel. We pass these through unchanged so your integration sees the same state machine in test as in live.