Schedule R | NFT Checkout Product Terms
Version 3.0 applies only through valid acceptance of the online MSA or a valid amendment. A private commercial order and provider approvals remain separate.
R.1 Actual approved flow
This schedule applies only to enabled NFT checkout. Schedule A and the activation record must identify the checkout/on-ramp/payment provider, Merchant, buyer collection recipient, asset/network, token function, fulfillment/redemption method and payout route. A card-funded digital-asset purchase and the subsequent token/utility and settlement steps must be described accurately. Do not substitute a generic Stripe Connect flow or assume every provider has the same merchant-of-record role.
R.2 Buyer clarity and underlying products
Before payment Merchant must explain the purchase, any NFT or digital-asset component, the actual seller, total price/fees, fulfillment and redemption rights, refund/cancellation terms and material blockchain risks. The NFT must represent the approved consumptive function. Merchant remains responsible for the underlying goods/services and lawful delivery. It must not disguise a prohibited physical or regulated product as an NFT, an investment, software or a research label.
R.3 Minting and redemption
Use only approved smart contracts, assets and networks and supported transfer/redemption controls. Keep records linking the authorized purchase, token issuance, entitlement and fulfillment. Do not duplicate entitlements or permit reuse after valid redemption/refund. A mint, burn or wallet event is not automatic proof that off-chain goods were supplied, does not determine legal classification and does not eliminate buyer rights or funding-side disputes.
R.4 Content and data
Merchant must own or license the relevant content and specify buyer rights. Do not add direct personal identifiers or confidential data to public-chain metadata; use minimal approved wallet/transaction references with a lawful basis, disclosures and appropriate off-chain safeguards. Record any contract administrator, upgrade, pause, transfer or burn powers accurately and disclose material buyer-facing features. RT makes no promise of universal technical reversibility or content deletion.
R.5 Payout and losses
Provider settlement and verified Merchant payout follow the agreed model. Card chargebacks, bank returns, required refunds and properly attributable provider assessments can arise after a token or stablecoin payout. Merchant must fund those obligations and any justified reserve. No blanket statement that token payments are irreversible may be used to deny a card dispute or required refund. USDC, USDT, Base, token standard, gas allocation and accelerated payout are included only if explicitly approved for the actual program.
R.6 Legality and service changes
Calling a token utility, a receipt or closed-loop does not establish a securities, payments, stored-value or licensing exemption. RT may suspend an unsupported or legally uncertain feature, require compliant changes and remove unlawful content from systems it controls. Merchant must arrange lawful fulfillment, refunds and content migration during wind-down; public records and third-party copies may persist. A provider's independent terms remain applicable.