Refunds

A Refund returns money against a confirmed Order. It is a financial record, not a change of mind: it does not cancel an entry, invalidate a credential, or free a seat unless something else does that.

Refunds are the most misunderstood part of commerce because two things share the word "cancel". Here they are kept apart, which is why an Order can be fully refunded and still hold a live entry.

• Against

  A confirmed Order

  Not a pending or expired one

• Goes to

  The original payment method

  Through the same merchant account

• Cap

  The Order's grand total

  Counted across all refunds

• Fee

  Returned in proportion

  Ulsav gives back its share of the refunded amount

• Cancels

  Nothing

  Refund and cancellation are separate

• Records

  Append-only

  Edits are impossible by design

Refund is not cancellationCopy Anchor Link

A partial refund alone leaves the buyer's entry valid. A cancellation alone returns no money. When you cancel an entry and refund it, the money moves first and the cancellation commits second, so a buyer is never cancelled without the refund that went with it.

Refunding a paid entry to zero and then cancelling it is an organizer decision. A buyer cannot unilaterally give up their own refund by cancelling.

The cap is a hard edgeCopy Anchor Link

Refunds are checked inside the transaction that creates them, not by the screen that requested them. Two refunds requested at the same moment cannot together exceed the Order.

$$\sum \text{non-failed refunds} \le \text{Order grand total}$$

Failed and cancelled refunds do not count, so a failed attempt can be retried for the same amount.

There is a second cap above that one: a single refund larger than the platform's direct-refund limit — ₹50,000.00 by default — is refused by policy, not parked for approval. Ask for a smaller amount, or ask Ulsav to raise the limit for the Organization.

The fee comes back in proportionCopy Anchor Link

When a refund succeeds, Ulsav returns its platform fee and the tax on it in the same proportion as the refund. A full refund returns the fee in full; a quarter refund returns a quarter of it.

$$\text{fee returned} = \left\lfloor \frac{(\text{fee} + \text{fee tax}) \times \text{refund}}{\text{grand total}} \right\rfloor$$

Amounts are whole paise, so the share rounds down. The organizer's own tax is reversed by the same proportional rule.

The full refund of Order ORD-000123 (₹3,894.12):

$$\text{refund} = \text{organizer share} + \text{organizer tax reversed} + \text{fee returned}$$

Refund amount

equal to the Order total

₹3,894.12

Organizer tax reversed

all of CGST + SGST

−₹567.00

Fee returned, with its GST

₹150.10 + ₹27.02

−₹177.12

Organizer share reversed

₹3,150.00

A full refund returns everything, so the fee comes back whole: ₹150.10 of fee plus ₹27.02 of tax on it.

The partial refund of the Workshop line (₹2,223.52) shows the proportions:

$$\text{share} = \left\lfloor \frac{\text{component} \times \text{refund}}{\text{grand total}} \right\rfloor$$

Refund amount

₹2,223.52

Fee returned, with its GST

−₹101.13

Organizer tax reversed

−₹323.75

Organizer share reversed

₹1,798.64

Each share is a whole number of paise, rounded down: the fee share is 177.12 × 2,223.52 ÷ 3,894.12 = ₹101.13, and the tax share is ₹323.75.

The three rows add back to ₹2,223.52 exactly. That is the rule to remember: a refund is split, never re-derived, so no paisa appears or disappears.

Refund statesCopy Anchor Link

A failed refund is not a loss. It stops counting toward the cap, so the same amount can be requested again once the cause is fixed. Refunds stuck in processing are polled by a worker until the provider gives a final answer.

Above-cap requests never reach a requested state: they are refused outright, which is why there is nothing to approve in a queue.

The ledger and the credit notesCopy Anchor Link

A succeeded refund writes reversing entries against the same accounts the sale credited, so the net position of a fully refunded Order is zero. It also issues one credit note per seller that had issued an invoice — one from you, one from Ulsav.

A refund of money that never became a sale is different: a late or duplicate capture is refunded in full, reverses a payable rather than revenue, and issues no credit note, because no invoice was ever issued.

Automatic refundsCopy Anchor Link

Two cases refund without anyone asking:

• a payment captured after the Order expired or was cancelled
• a second capture on an Order that is already confirmed

Both refund the exact captured amount, skip the direct-refund cap, and need no capability check, because they are Ulsav correcting its own books. The refund record is unique per provider payment, so redelivery cannot refund twice.

Event cancellationCopy Anchor Link

Cancelling an Event cancels every Registration, closes every pending checkout, releases every hold, and refunds every paid Order in full. It is idempotent and resumable: if a provider call fails, a worker retries any Order still owed money.

Where refunds appearCopy Anchor Link

There is no refund button in the organizer app yet. A refund is issued through the refunds API, and then shows up in three places: the Order's Refunds tab, the Finance → Refunds list, and the buyer's own account under Refunds.

Every refund records the amount, currency, reason, the person who asked, the entries it names, and the provider references.

Failure pathsCopy Anchor Link

RelatedCopy Anchor Link

• Orders — the record being refunded
• Payments — confirmation and the ledger
• Invoices — the credit notes a refund issues
• Cancellation reference — what a cancellation owes a buyer