Refunds

Giving money back is one call. The hard question comes after: does the buyer still have the product? With a digital product they already downloaded it, and the link is still in their inbox.

This page answers both.

The refund is against the payment, not the invoice

An invoice can have several charge attempts and only one took the money. That is the one you refund.

const [payment] = await infi.payments.listForInvoice(invoiceId);
await infi.payments.refund(payment.id, { reason: "customer changed their mind" });

Only a confirmed payment can be refunded, and where the money comes from depends on your collection model. Under BYOP the refund runs on the provider account you connected: it is your money leaving your account. Under Infi Managed the charge was received on our structure, so the refund leaves from there and is deducted from your payout — including future payouts, if the amount was already paid out.

Full or partial: the amount decides the access

Omitting amount refunds everything. And here is the rule that matters:

The logic: a full refund undoes the sale, so the capability the sale created has to die with it. A partial refund does not undo the sale — R$5 back on a R$100 guide is goodwill, not a cancellation — and cutting the file there would punish exactly the customer you just tried to please.

An amount above the total is treated as full, not refused.

When you want the opposite

// refund everything and let them keep the file
await infi.payments.refund(payment.id, { revokeAccess: false });
 
// cut access even when refunding only part
await infi.payments.refund(payment.id, { amount: "5.00", revokeAccess: true });

revokeAccess: false is the policy of plenty of info-products: fighting costs more than the file. Do not send the field if you do not mean to override — the derivation above is the right behaviour in almost every case.

What the buyer sees afterwards

Their old link answers 410 Gone, with error_code and message in the body:

{
  "error_code": "download_revoked",
  "message": "This download is no longer available: the purchase behind it was refunded."
}

410 and not 404, on purpose. Whoever holds the token already proved they hold it, so "this existed" leaks nothing — and a 404 would look like a broken link, which turns a settled refund into a support ticket.

On your page, the grant comes back with revokedAt and stays in the list:

const [grant] = await infi.invoices.deliverable(invoiceId);
if (grant?.revokedAt) showRefundNotice();
else if (grant) showButton(grant.downloadUrl);

It does not disappear, because a grant that vanished would look like fulfilment that never ran — two very different problems wearing the same face.

Reading what you refunded

status does not answer how much came back: a partial refund also leaves the payment as refunded. What answers is refundedAmount.

const p = await infi.payments.get(payment.id);
p.status;          // "refunded"  — even with only R$5 returned
p.refundedAmount;  // "5"         — R$5 given back
 
await infi.payments.refunds(payment.id);
// [{ id, amount: "5.00", createdAt }]

The values are decimal strings with no guarantee of two places: "5" and "5.00" are the same amount. Do not compare the raw text to decide how much came back.

refunds() returns the individual records, with amount, date and identifier. The reason field is optional in the response.

The invoice stays paid

On purpose. The invoice records that it was paid, because it was — and accounting does not erase a fact, it posts the opposite of it. The refund is its own record, with its own reversing entry in the ledger.

Practical consequence: if you sum paid invoices for your sales report, a refunded sale counts in full. Subtract refundedAmount from the payments.

Webhook

A refund emits payment.refunded, with accessRevoked saying whether the download fell:

{ "paymentId": "…", "invoiceId": "…", "amount": "100.00",
  "currency": "BRL", "accessRevoked": true }

accessRevoked is there because your own system almost always has access of its own to cut — a subscription, a feature flag, a Discord role. Subscribe in webhooks.

A chargeback is the same mechanic, without you

When the buyer disputes at their bank, the provider sends PAYMENT_REFUNDED or the chargeback event and the same path runs: the payment becomes charged_back, a reversing entry is posted, and access falls — the network takes the full amount, so the amount-based derivation revokes. You do not have to do anything, and you cannot prevent it.

The emitted event is payment.chargeback.