Schedule F | Operating Rules and Processing Procedures
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.
F.1 Readiness
Use approved integrations and current supported versions. Test success, failure, decline, duplicate, pending, timeout, webhook, refund, payout and reconciliation cases before production. Do not use real card credentials or unnecessary personal data in test environments. RT/provider production approval is required separately from contract acceptance.
F.2 Order and payment states
Keep order creation, authorization, capture, clearing, token minting, redemption, settlement and payout as distinct states. Fulfillment must follow the appropriate confirmed state for the method and product. Use immutable transaction references and idempotency keys. An uncertain request must be reconciled before retry, and duplicate charges or credits must be corrected promptly through the provider process.
F.3 Customer information and receipts
Clearly identify Merchant, the purchased goods/services, total paid, currency, taxes and fees, support contact and material fulfillment/refund terms. Retain evidence of required consent and product-specific disclosures. Do not put sensitive personal data in receipts, metadata or logs beyond what is necessary and permitted. A token receipt is additional evidence, not proof that a separate physical product was delivered.
F.4 Refunds and dispute files
Submit refunds promptly under applicable deadlines, using linked original-transaction references. Track chargebacks and refunds together to prevent duplicate repayment. Supply factual evidence responsive to the actual reason code; do not include prohibited authentication data. Meet RT's notified cutoff, ordinarily responding within two Business Days or sooner for a real external deadline. RT may require advance funding for reasonable external escalation costs.
F.5 Daily controls
Reconcile orders, provider events, gross amounts, fees, reserves, adjustments and payouts; investigate mismatches promptly. Monitor webhook failures and pending transactions. Keep dispute and risk contacts current. Preserve necessary records and evidence under applicable retention rules without retaining payment credentials or personal data indefinitely.
F.6 Changes and interruptions
Inform RT before changing domains, accounts, product scope, ownership, fulfillment, ticket size or volume materially. Implement required security patches and provider/API changes by the reasonable notified deadline. During an outage stop unsafe processing and follow documented provider fallback instructions only where expressly supported; this schedule does not authorize offline capture or voice authorization by default.
F.7 Support and enforcement
Report payment/security incidents to the channels in Schedule K, supplying transaction IDs and timestamps rather than secrets. RT may restrict unsafe integrations, re-underwrite, require remediation or apply core risk controls. A technical log or support response cannot amend pricing, approve a restricted activity or authorize a new funds flow. Changes to these binding rules follow core Section 16.