Crypto Billing Refunds After Settlement: A Decision and Reconciliation Playbook

Which remedy fits this settled subscription charge?

Choose the remedy by asking what the approved adjustment is meant to do. If it returns value from a charge that has already settled, classify it as an outgoing refund, not a reversal of the original payment. If the adjustment is meant to reduce a later invoice and the applicable terms permit that treatment, classify it as account credit. If eligibility depends on an unused or changed portion of service, determine the prorated entitlement first; its result must still become either a refund or a credit. Any material gap sends the case to review. This guide’s rule is to make one classification from the case facts and controlling provision, rather than offering the customer a convenient-looking menu after the fact—it is an adjustment decision, not a tapas order.

Test that rule against a hypothetical duplicate settled subscription charge. Suppose the case file links both payments to the same subscription period and an authorized decision establishes that one completed charge should be reimbursed. The fitting remedy is an outgoing refund: a confirmed payment is not simply undone, so the approved value moves through a separate payment. Before accepting that classification, identify the stated amount basis independently from the delivery details. Amount questions include whether the obligation follows the original asset quantity or a fiat-denominated value, and whether a valuation time, precision, or rounding method applies. Delivery questions include the recipient, destination, asset, network, and fee treatment. The duplicate-charge label is only a hypothetical trigger; it does not establish that reimbursement is owed.

Change one fact and the outcome may change. A hypothetical downgrade that affects only a later invoice may fit account credit if the operative terms authorize retained value. A hypothetical period of unused service may call for proration if eligibility is defined by service units. An asserted wallet claim with inconsistent destination details belongs in manual review even if the amount appears obvious. Stop there as well if authority, entitlement, payment linkage, amount basis, recipient, asset, network, or fee treatment cannot be established without assumption. The selection should document why the case entered that branch and which provision controls it. Record one remedy class, the triggering event, the applicable provision, and any disqualifier that sends the case to review.

Which inputs must be established before approval?

Before approving the selected remedy, establish the denomination in which the entitlement is recorded, the eligible quantity or service units, and—if conversion is required—the valuation source and policy-defined timestamp. Also specify the calculation precision, rounding rule, proposed receiving address, asset, network, recipient relationship, authorization evidence, and published treatment of the network fee. Read these fields together: the amount identifies the obligation, while the recipient and destination fields identify where an approved outgoing payment may go. For this decision, treat any missing, contradictory, or unauthorized field as unresolved; an appealingly complete-looking wallet string is not a substitute for a complete case file. The outgoing payment itself still requires an approval basis and timing.

If the remedy returns the original asset, record the eligible original-token quantity as Q. For a transparent hypothetical conversion, let V be the eligible fiat value and P the documented fiat price per token at the defined timestamp; the resulting token amount is V / P. For a time-based entitlement, let B be the adjustable plan price, U the eligible unused units, and T the total period units; the entitlement is B × U / T. Record the applicable expression, each input, precision, and rounding result without filling a gap with a convenient price or fee. Where a fee applies, show the gross obligation, network fee, merchant outflow, and recipient net amount separately so the published fee rule can be tested against the proposed figures rather than buried in the arithmetic.

Next, test the destination information as a recipient claim, not merely as a technical address. A sending address alone does not establish the contractual recipient: it may represent another person, a different network, an exchange account, or a service with incoming-transfer limits. Identify whether the proposed recipient is the company, original payer, an employee, or another party, then attach the evidence authorizing that relationship and destination. Rules that return centralized payments to the original payment method do not establish a universal blockchain-address rule, so do not borrow that shortcut for an outgoing on-chain payment. Complete an input sheet and assign an exception owner for every absent, contradictory, or unauthorized field. Only approve the remedy when every required field is resolved under the applicable written rule.

How should an approved outgoing adjustment move through reconciliation?

Take one hypothetical approved adjustment: the recorded gross obligation is 50 tokens, the actual network fee is 0.20 token, and the applicable policy requires the merchant to absorb that fee. The customer must therefore receive 50 tokens, while the merchant’s total outflow is 50.20. Begin by linking the case to the settled charge and recording the inputs that produce the 50-token obligation. Then confirm that the proposed recipient, address, asset, and network have each been authorized for this case. Record the approved fee treatment, expected customer net, and expected total outflow before any payment instruction is released. These figures illustrate the arithmetic only; they do not establish a market fee, approval authority, processing time, or generally permissible fee treatment.

After authorization, create the outgoing payment as a transaction separate from the settled charge. Record the case identifier on the payment instruction, submit it, and change the case state only when the submission record exists. In this example, the first incomplete state is execution capture: the instruction shows as submitted, but no execution reference has yet been attached. Test that state by checking for a definitive execution result tied to the instruction—not by assuming that submission means completion. If the reference cannot be produced, keep the case open and assign it to the named exception owner. If it is produced, attach it along with the executed amount, recipient, asset, network, and actual fee, then proceed to reconciliation. The distinction is deliberately unglamorous: “sent” is an event; closure is an accounting conclusion.

Reconcile the execution record against the authorization record field by field. For this case, confirm that the executed customer net is 50 tokens, the captured fee is 0.20 token, and the resulting merchant outflow is 50.20; also compare the executed destination, asset, and network with their authorized values. Mark the case matched only if every required comparison agrees and the execution result is present. If any amount or routing field differs, or if the result remains unresolved, record the observed variance and assign the case as an exception without guessing at its cause. This sequence separates the obligation, fee, customer net, and total outflow, while recognizing that the payment itself cannot undo the original confirmed transaction. Advance the case state only when the required record for that state exists, and route mismatched amounts, destinations, assets, networks, fees, or execution results to the named exception owner.

What record should you create first for an auditable decision?

Create the merchant-controlled adjustment ledger entry first, anchored to the settled payment rather than treated as a modification of it. For the selected scenario, open `[CASE-ID]` against `[SUBSCRIPTION-REF]` and `[ORIGINAL-TX]`, then record `[EVENT]`, `[REFERENCE]`, and the completed classification `[VALUE]`. Because a confirmed network transaction is not simply reversed, the remedy must remain a distinct record connected to that source. Use this guide’s audit rule: a reviewer should be able to move from the source charge to the decision, calculation, authorization, execution evidence, and final comparison without relying on chat history or an operator’s memory. The ledger is therefore the first durable deliverable, not an after-the-fact note assembled when someone asks an awkward question.

A copyable implementation row is: `case_id=[CASE-ID]; subscription_ref=[SUBSCRIPTION-REF]; original_tx=[ORIGINAL-TX]; event=[EVENT]; policy_basis=[REFERENCE]; classification=[VALUE]; source_basis=[TOKEN/FIAT/SERVICE]; formula_inputs=[VALUES]; destination_authorization=[IF APPLICABLE]; fee_rule=[VALUE]; approval=[STATE/APPROVER]; remedy_ref=[OUTGOING-TX OR CREDIT-ENTRY]; amounts=[GROSS/FEE/OUTFLOW/NET]; reconciliation=[OPEN/MATCHED/EXCEPTION]; exception_owner=[OWNER]`. For this scenario, preserve the recorded 50-token obligation and the 0.20-token fee as separate values; if the merchant absorbs that fee, enter 50 tokens as customer net and 50.20 tokens as merchant outflow. Store the chosen price observation and its time only if conversion was part of the calculation, and retain the exact formula operands plus the applied decimal and rounding convention so the result can be reproduced. If value is sent, attach the authorized routing evidence and the resulting transaction reference; if the remedy remains internal, attach its credit-entry reference instead.

• Case identity — case ID, subscription reference, original transaction hash, triggering event, and governing policy or contract provision.
• Classification — outgoing refund, account credit, prorated adjustment, or manual review, including the reason and any disqualifier.
• Calculation — source denomination, formula, eligible quantity or service units, valuation source and timestamp if conversion is required, precision, rounding, and gross obligation.
• Destination authorization — proposed address, recipient relationship, authorization evidence, asset, and network when an outgoing transfer applies.
• Fee treatment — published fee rule, estimated network fee, actual network fee, merchant outflow, and customer net amount.
• Approval — current state, approver, approval time, conditions, and named exception owner for unresolved fields.
• Remedy evidence — outgoing transaction hash or internal credit-entry reference, execution time, and relevant status evidence.
• Reconciliation — expected versus actual asset, network, destination, gross obligation, fee, merchant outflow, and customer net; close as matched or retain as an assigned exception.

Make closure a controlled state change. Require the source-payment link, completed decision fields, authorization where relevant, approval identity, remedy evidence, and amount comparison before allowing `MATCHED`. If any required value is absent or a comparison differs, leave the record at `EXCEPTION` and name the person responsible for resolving it; do not fill gaps by inference. This schema is a recommended merchant operating control, not a verified Zyrox capability: the available product description establishes gateway support for specified digital assets, recurring billing, smart-contract subscriptions, payouts, payment links, webhooks, integrations, and API access, but does not establish native adjustment handling, proration, address verification, approval routing, record identifiers, exports, or reconciliation controls. Nor does this ledger replace applicable accounting, tax, sanctions, consumer-protection, or record-retention procedures. Implement it in the merchant’s operating system, require links to both the originating payment and remedy evidence, and block closure unless reconciliation is matched or an exception owner is assigned.