On this page

Payment Credits & DeFi

Redeem settled payment credits for their backing asset and recover the payout as a private note.

Settle the payment before redeeming its credit#

Sessions, subscriptions, authorization/capture and streaming billing resolve purchases and refunds in the payment contracts and app. FuyuPaymentCreditAdapter starts after that work: it takes transferable settled credits and redeems them for backing assets. The Pool does not decide a voucher dispute or release an authorization hold.

One credit unit redeems for one native underlying unit. The issuer must settle claims, vouchers and refunds before creating credits. The adapter takes no session ID, merchant override, beneficiary or arbitrary calldata. Its callback only moves settled credits into backing assets for private settlement.

A private input, a public action and its returned note
A private input, a public action and its returned note

Check the issuer and backing token#

The issuer must expose asset, totalSupply, balanceOf, transferFrom and redeem(amount, receiver). Review backing, issuance/burn accounting, transfer behavior and upgrade policy. Deploy the adapter with distinct Pool, credit and underlying addresses, all with code, and check credits.asset() against the underlying.

The adapter stores chain and runtime hashes for those contracts and checks them before and after redemption. Also check proxy implementations and issuer administration in the release: a proxy can change implementation while keeping its runtime hash. The credit's backing and issuer risk remain relevant when the credit is held inside the Pool.

solidity
interface IFuyuSettledPaymentCredit {
    function asset() external view returns (address);
    function totalSupply() external view returns (uint256);
    function balanceOf(address owner) external view returns (uint256);
    function transferFrom(address from, address to, uint256 amount)
        external returns (bool);
    function redeem(uint256 amount, address receiver)
        external returns (uint256 assets);
}

Register credit redemption#

REDEEM is operation 0. The input token is the settled credit and the output is its backing asset. amountIn must be positive and no larger than uint128.max. minOut must be positive and no greater than amountIn. actionData is zero, and the inclusive deadline is checked onchain. Admit the credit asset and register this adapter route before using it.

The conversion is one-to-one in native units. For a six-decimal backing token, redeeming 1000000 credit units must return 1000000 asset units. This says how redemption is accounted for, rather than setting the asset's fiat price. If the issuer cannot pay that amount, the action reverts.

FieldValue or constraint
operation0: settled-credit redemption
amountInPositive native credit amount, at most uint128.max
minOutPositive backing-asset floor, no larger than amountIn
actionDatabytes32(0); no session or beneficiary fields
tokenOut / amountOutConfigured backing asset / measured 1:1 output

Check the credit burn and asset transfer#

The callback records adapter and Pool credit/asset balances, plus total credit supply. It pulls the input from the Pool and checks that transfer left supply unchanged. It then redeems to the Pool, checks that supply fell by the input amount and requires the adapter's balances to return to their starting values.

Both the issuer's return value and the Pool's asset increase must equal amountIn. An issuer that reports payment without transferring it fails. Existing adapter donations stay out of this output. The Pool separately verifies spend authority and token deltas, then clears the input allowance.

Connect the payment lifecycle to the Pool#

A Session app deposits a budget, accepts small cumulative authorizations, consumes service credit atomically and settles merchant income or the final refund. Once the issuer creates settled credits, the holder can redeem publicly or deposit through the asset/profile admission flow. A Pool-held credit can then use this action to create an underlying settlement.

The SDK does not automate those deposit and recovery steps. Session funding refunds a public credit to its fixed recipient; it does not create recovery material or a private refund note. Build and check that deposit path in your app. A card authorization hold must finish settlement before it can be treated as a settled credit.

Recover the payout and keep payment state separate#

Redemption exposes issuer, credit amount, underlying payout and timing. The payment app can also associate requests within a session. Private funding can reduce direct linkage to a long-term wallet under the protocol's assumptions, but merchant, network and controller data remain relevant. The issuer's payment history remains public after credit redemption.

Deploy Session/Funding contracts and enable the credit asset through their own release. That release needs issuer/adapter identities, backing and proxy policy, publisher registration, persistent billing accounting and lifecycle tests. Stage 1 reserves the backing payout; finalization and a scan recover the private note. Track the credit liability separately from the note's settlement state.

Find an accounting mismatch#

BindingChanged means chain, code or the asset relationship changed. InexactInput means the pull changed balances or supply unexpectedly. InexactConsumption means the burn, remaining balances or supply decrease failed a check. InsufficientOutput means the reported or received payout differs from the one-to-one amount. Changing minOut cannot make another conversion rate work with this adapter.

FuyuPaymentCreditAdapter tests cover this callback. Test dispute and close timing, refunds, shared collateral, issuer solvency and recovery in the payment app too. The callback's accounting checks apply to already settled credits; provider behavior and unsettled sessions need their own tests and deployment checks.