Corrections

Your team always has the last word. Every correction is built from two moves, attach a deposit to a payment and detach it, and the payment's amounts and status are recomputed from its deposits afterwards. Approving a receipt attaches a deposit too. Nothing is adjusted by hand, so a correction can never leave a total wrong.

Each correction is recorded in your account's audit log with who made it and why, and appears in the payment's evidence pack.

The tools

Everything that decides about money (receipts, attach, detach, approve, accept the shortfall, reject, resolving an overpayment) needs the corrections permission: owner, admin and support members. Top up, extend and cancel need the write permission, which developers have too. In the dashboard detach, approve, accept the shortfall, reject and cancel ask for a reason of 3 to 500 characters.

Receipts

• Approve puts exactly one deposit behind the receipt and recomputes the payment. Receipts and review has the amount rules.
• Reject never touches deposits. The payment waits for the customer again when it has no other pending receipt.
• Back to review puts a rejected receipt back to pending and the payment back to Awaiting approvalprocessing.
• An approved receipt is undone by detaching its deposit. The receipt goes back to pending and its deposit of source receipt becomes Reversedreversed (it stood for nothing but the approval). Approve it again and a new deposit is made.
• A receipt deposit replaced by the bank SMS is stored as reversed too, but the dashboard and the evidence pack label it Replaced by the bank SMS, beside the SMS deposit that took its place. Nothing to do: the money is counted once.
• Link to receipt says that an unmatched bank deposit is the transfer a receipt shows, for an SMS the engine could not place for sure (two receipts of the same amount, say). A pending receipt is approved on that deposit; an approved receipt standing on its own receipt deposit has it replaced by the SMS deposit, at the bank's amount. The deposit must be on the payment's card or account. When that adds more than the payment still asks for, the link shows that overpayment and asks you to confirm it first.

Attach and detach

curl https://a.bezanbecard.com/v1/payments/pay_…/attach_deposit \
  -H "Authorization: Bearer sk_test_…" \
  -H "Idempotency-Key: attach-dep_…" \
  -H "Content-Type: application/json" \
  -d '{"deposit":"dep_…"}'

• Attaching a deposit that is already on a payment is refused with deposit_already_matched: detach it there first.
• Attaching a bank SMS by hand to a payment that holds a receipt deposit of the same transfer replaces that deposit instead of adding money; when two or more receipt deposits there could be that transfer, it replaces the oldest.
• A detached deposit goes back to unmatched and through matching again, but never back to the payment it left. In the dashboard you can keep it unmatched instead. A receipt's own deposit is reversed instead, as above.
• If a payment that had succeeded loses all its deposits, it goes to review with the reason detached.

Approve a payment

Approving a payment closes it as Succeededsucceeded with what arrived; the difference is recorded as amount_shortfall. The API requires a reason. To approve the money on a receipt, approve the receipt instead.

await bezanbecard.payments.approve('pay_…', { reason: 'Customer paid the rest in cash' });

Recording a deposit by hand

When you see a transfer in your bank app that nothing brought in, record it. card and amount are required; add channel (card, pol, paya, satna or internal), payer_last4, the bank's trace number in bank_reference and occurred_at (unix seconds) when you have them. The same card or account and trace number twice is one deposit, so a transfer you record that later also arrives by SMS with the same trace number is not counted twice.

const deposit = await bezanbecard.deposits.create({ card: 'card_…', amount: 12_500_470, bank_reference: '402911' });

The new deposit goes through matching like any other. In the dashboard you can attach a photo of your bank's record as well. When the customer's receipt is already in your queue, approving the receipt is simpler: it records the deposit for you.

Clearing the review queue

Every correction emits the usual events (receipt.approved, payment.succeeded, deposit.matched, deposit.unmatched and so on), so your systems hear about a fix made in the dashboard just as they hear about one made through the API.