StatusPrivate betaPublic testnets — test tokens, no real valueMainnet rolls out per jurisdiction

After payment

Refunds

Refunds work differently when no one holds your money. RSends never took custody of the payment, so RSends cannot send a refund — only you can, from the wallet the funds settled into.

Why RSends can't refund for you

When a customer paid, the stablecoin moved directly from their wallet to your wallet on-chain. RSends was never in that path — it only observed the event. It has no balance of yours to draw from and no key that can move your funds. There is nothing for it to send back.

A refund is a payment in reverse

To refund a customer, you send a transfer from your own wallet back to their address — the same way you'd send any on-chain payment. You choose the amount, the token, and when. RSends is not a party to it.

How to refund

StepAction
1Look up the original payment (its tx_hash and the payer address) in Reporting or on BaseScan.
2From your merchant wallet, send the refund amount in the same token back to the payer address.
3Record the refund against the original payment in RSends, for your reporting (below).

Recording a refund

RSends can record that a payment was refunded so your reporting reflects it — it sets the intent's status to refunded. This is bookkeeping only: recording a refund never moves money. The actual transfer is the one you sent from your own wallet.

POST/api/v1/merchant/payment-intent/{intent_id}/resolve
record a refund (resolve action)
curl -X POST https://pay.rsends.io/api/backend/api/v1/merchant/payment-intent/\
pi_9f1c4a7e2b5d8036c1e94ab7d2508f63/resolve \
  -H "Authorization: Bearer rsend_test_YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{ "action": "refund" }'

// → intent.status becomes "refunded" (a record). No funds move.

This endpoint only accepts intents in review

resolve is the decision point for a payment held in review — the state a late payment lands in under late_payment_policy: "review". Calling it on a normally-completed payment returns 400 INVALID_STATE. There is currently no endpoint that records a refund against a completed intent: for those, keep the refund in your own books and reconcile against the on-chain transfer you sent. The other action here is {"action": "complete"}, which accepts the held payment and fires payment.completed_late.

The record is not the refund

Marking an intent refunded does not pay anyone. Always send the on-chain transfer first, then record it. If you record without sending, your customer is still out of pocket.

What this means in practice

  • You control refund policy and timing entirely — there is no processor window or reserve.
  • Refunds are merchant-recorded, not processor-driven; there is no inbound “refund” webhook from RSends, and no payment.refunded event exists.
  • The refund transfer is itself a public on-chain transaction your customer can verify.