Complaint to refund in one governed minute.
The support agent reads the ticket, verifies the order against the ERP, refunds on the original payment rail, issues the credit note, and tells the customer — all inside a per-agent spend limit. Support stops escalating refunds; finance stops discovering them at month close.
Verified, refunded, sealed — inside the conversation.
The customer complains where they already are: WhatsApp. The agent pulls order #8421 from the ERP, confirms the Pix payment it settled on, refunds to the same key, and issues the credit note. The spend limit is a mandate, not a policy PDF — a refund above the cap simply does not execute.
- Order verified against the ERP before a cent moves back
- Refund runs on the original rail — Pix back to the payer's key
- Credit note issued in the same flow, sealed to the refund receipt
The conversation is the easy part.
Refunds are where support meets money and both teams flinch. The ticket waits for someone with bank access, the bank transfer does not match the original payment, the credit note is remembered a week later, and nobody can say afterwards who approved what. A one-minute problem becomes a three-day thread.
Escalate every refund to whoever holds the bank login
The agent refunds inside a per-agent mandate cap — no shared login
Refund by manual transfer, disconnected from the original charge
codespar_pay returns the money on the original rail, same Pix key
Issue the credit note later, if someone remembers
codespar_invoice cuts the credit note in the same flow
Answer the auditor with a Slack thread and a bank print
Verification, refund and note sealed into one receipt
Refunds with a spending limit, not a shared login.
codespar_ledger verifies the order and its original payment before anything moves. codespar_pay executes the refund on the same rail it settled on, bounded by the support mandate — a signed cap per agent, revocable at any time. codespar_invoice issues the credit note and codespar_notify closes the loop with the customer, all sealed into one auditable record.
Complaint · order #8421
codespar_ledgerOrder + original payment
Omiecodespar_payPix · original key · cap
Pix railcodespar_invoiceNC issued + stored
Fiscal railcodespar_notifyCustomer confirmed
Z-APIThe ticket enters from the support channel. The agent resolves the order in the ERP, confirms the original settlement, and executes the refund under the support mandate — a per-agent cap the policy engine enforces at run time. The credit note is issued against the refund, the customer is notified, and all four steps seal into one receipt.
A few lines. The whole loop.
const session = await codespar.sessions.create(); // verify before moving money: order, amount, original rail const order = await session.execute("codespar_ledger", { action: "lookup", orderId: "8421", }); await session.execute("codespar_pay", { rail: "pix", amount: order.total, // R$ 186,00 destination: order.payer.pixKey, // original key, original rail mandate: "cm_support", // per-agent cap · revocable }); await session.execute("codespar_invoice", { kind: "credit_note", orderId: "8421" }); await session.execute("codespar_notify", { to: order.buyer, template: "refund_done" });
codespar_payRefunds on the original rail, bounded by the per-agent support mandate.
codespar_ledgerVerifies the order and its original settlement before the refund runs.
codespar_invoiceIssues the credit note in the same flow and seals it to the refund.
Ship it this afternoon.
Open the sandbox, point a session at your providers, and run the whole loop against real rails in minutes — not the quarter it takes to build it by hand.