Payments, fees, and compliance
Payment rules, refundability, dunning behavior, and gateway setup.
This section describes how payments are collected and how the platform behaves on failures.
It also captures the refund rules and the dual-gateway model.
Payment management
Auto-pay is mandatory for all accounts.
Card details are handled by the payment gateway. The platform stores only tokenized card data.
14.01
Accepted payment mode
Credit / debit card
Primary method for all transactions.
14.02
Auto-pay
Mandatory
Cannot be disabled.
14.03
Save card on file
Mandatory
Required for auto-pay and retry logic.
14.04
Payment gateway
Brand-configured
Brand confirms gateway choice and provides credentials (if applicable).
14.05
Tax engine
Brand-configured
Brand confirms tax engine choice and provides credentials (if applicable).
14.06
Card management
Yes
Card entry happens on the gateway-hosted page. Platform stores token only. Add secondary cards and change default card are supported.
14.07
Payment failure retry
Day 0 + 1
Next-day retry after a failed payment. Decline codes include: 530 (Do Not Honor), 302 (Credit Floor), 521 (Insufficient Funds).
Refund policy
Refundability depends on the charge type.
No refunds are issued for mid-cycle disconnections or port-outs.
Data top-ups are non-refundable.
Data top-up
No
Non-refundable in all cases.
Activation fee
Yes
Refundable per policy.
Reactivation fee
No
Non-refundable.
Plan MRC (mid-cycle)
Yes
Pro-rated refund applies per policy.
Shipping charges
Yes
Refundable per policy.
Dunning and non-payment policy
When a payment fails, the platform follows a defined dunning process.
The full schedule (exact day-by-day timing) is maintained separately.
Initial payment attempt
Bill due date (Day 0)
Auto-charge card on file
Auto-pay is mandatory.
Payment retry
Day 0 + 1
Automatic retry
Standardized decline handling.
Service suspension
Per dunning schedule
Hotline / suspend
Use the Dunning Policy Sheet for exact timing.
Voluntary disconnection
End of billing cycle
Disconnect
No mid-cycle refunds.
Involuntary disconnection
30 days post-suspension
Disconnect
Dues must be cleared before reconnection. After 30 days, the number is recycled.
Multi-payment gateway support
The platform can run two gateways in parallel.
This avoids disruption for existing customers while onboarding new customers onto the default gateway.
Saved card data is not migrated between gateways.
Primary gateway (new users)
Stripe
New users and newly added payment methods use Stripe. Stripe uses Reach-owned credentials.
Secondary gateway (existing users)
IPPAY (legacy)
Existing users continue with their stored legacy payment methods.
Payment methods supported
Card (default) + ACH (optional)
ACH enablement requires additional ops setup.
Customer UX
No gateway differentiation on Web/App
Reach Central indicates the gateway used.
Reporting
Enhanced with gateway metadata
Reports include Payment_Gateway_Name. Impacted reports include Daily Payments and Monthly Refunds.
Branding
Tenant-wise via Stripe Checkout
Stripe descriptors support static and dynamic brand components.
Commercial terms
Shared separately
Commercial terms are handled via cost recovery discussions.
Questions or clarification? Reach out to your respective account manager or email at [email protected]
Last updated