Variable amount · tiered · partial

A sliding scale payment system that stays out of your policy.

topropay is the payment infrastructure underneath the merchant's own sliding scale — variable amounts at authorisation, tiered subscriptions on one engine, partial payments against a balance, and per-tier receipts. The scale, the tiers, the eligibility — those stay on the merchant side.

Book a tier-model review Read the API docs
Variable
Any amount at authorisation — the merchant sets the scale
Tiered
Multiple subscription tiers on the same billing engine
Partial
Buyers pay against a balance across visits

Key benefits

Why a sliding-scale merchant picks a flexible payment surface

Four properties the merchant relies on the moment their pricing stops being a fixed SKU and starts moving with the buyer.

  1. 01

    Variable amounts at authorisation

    The authorise endpoint accepts any amount the merchant passes — €5, €50 or €5,000 against the same integration. A sliding-scale merchant sets the amount server-side per buyer's chosen tier; topropay handles the routing, capture and reconciliation.

  2. 02

    Tiered subscriptions on one engine

    Multiple subscription tiers (support-what-you-can, standard, patron) run on the same recurring engine with the same vault tokens. Buyers can upgrade or downgrade between tiers without a re-entry of card details.

  3. 03

    Partial payments against a balance

    A buyer can pay against a running balance in multiple installments — useful for scale-of-service billing where the buyer contributes over time. Each part-payment gets its own reconciliation row tagged with the parent balance ID.

  4. 04

    Per-tier receipts and reporting

    Receipts carry the buyer's chosen tier (or the calculated sliding-scale amount) in the description line; finance reports split by tier for programme reporting and grant compliance where relevant.

How a sliding-scale flow plugs in

From merchant policy to a tier-tagged settlement row

What happens between the merchant defining their scale and the tagged row landing in finance's ledger.

  1. 01

    Merchant defines the scale

    The merchant runs their own sliding-scale policy — income bands, self-declared tiers, membership levels, whatever fits the programme. topropay is the payment surface; the policy stays on the merchant side.

  2. 02

    Buyer selects a tier or amount

    On the hosted checkout, the buyer selects the tier or enters the amount that matches the merchant's guidance. The chosen amount travels to topropay's authorise endpoint.

  3. 03

    Authorise and route

    The routing engine scores connected acquirers on BIN, currency, country pair and risk regardless of the ticket size. Same infrastructure serves the €5 tier and the €500 tier.

  4. 04

    Capture and, optionally, recur

    One-off: capture immediately. Recurring: enroll the vault token in the merchant's chosen tier and let the platform's recurring engine handle renewals and retries.

  5. 05

    Reconcile with tier metadata

    Each settlement row carries the tier (or the sliding-scale amount) plus the buyer identifier. Finance and programme reports split by tier for stakeholders and audit.

Main use cases

Where a sliding-scale flow earns its keep

Six recurring merchant shapes — non-profits, education, wellness practices, arts venues, SaaS support-us tiers and service businesses with income-adjusted rates.

  • NPO

    Non-profit and community memberships

    Non-profits offering support-what-you-can memberships — three or four tier prices with a self-declared band. Buyers see the tiers; the merchant sees the split of revenue per tier per month.

  • Edu

    Education and training programmes

    Community education, workshops and continuing-education programmes with income-adjusted fees. Each cohort gets a tier lookup; enrolments route through the same checkout.

  • Hlth

    Wellness, therapy and coaching practices

    Licensed practitioners running sliding-scale fee schedules for wellness, therapy and coaching. topropay is the payment rail; the practitioner's own admin system holds the fee schedule and the patient / client relationship.

  • Arts

    Arts and culture ticketing

    Museums, theatres and independent venues offering pay-what-you-can ticketing alongside a standard admission price. Each variant travels to the same authorise endpoint.

  • SaaS

    SaaS with pay-what-you-can early tiers

    Early-stage SaaS platforms running a support-us tier alongside standard subscriptions. The recurring engine handles both cadences on the same billing infrastructure.

  • Serv

    Service businesses with income-adjusted rates

    Consultancies, coaches and instructors offering income-adjusted rates for community clients. The merchant applies the discount server-side; the buyer's checkout shows the adjusted price.

Platform features

Capabilities the sliding-scale merchant relies on

Twelve capabilities the platform ships once and reuses across every tier, amount and buyer shape.

  • Variable-amount authorise

    Any amount at the authorise endpoint — the merchant's server sets the value per buyer.

  • Tiered subscription plans

    Multiple recurring tiers on the same engine; upgrade / downgrade against the same vault token.

  • Partial payments against a balance

    Running balance per buyer identifier; each contribution logged with amount, timestamp and method.

  • Payment plans (installment)

    Split a single balance into scheduled installments with card-on-file recurring on the vault token.

  • Hosted variable-amount pay link

    Per-buyer or per-programme pay link that accepts a variable amount from the buyer's side.

  • Tier metadata on every row

    Chosen tier or sliding-scale amount tagged on every settlement row for finance and programme reports.

  • Per-tier receipts

    Automated receipt with tier line item and, where applicable, tax-treatment marker.

  • PCI DSS Level 1 vault

    Card data captures into the platform vault before any acquirer sees it; PAN never lands on the merchant's system.

  • Smart routing across acquirers

    Per-BIN routing across the connected acquiring panel regardless of ticket size or tier.

  • Operator-side refund controls

    Refunds against the vault token with reason code, actor ID and timestamp logged.

  • Multi-currency where relevant

    Accept in the buyer's currency for cross-border community programmes; settle in the merchant's operating currency.

  • One reconciliation feed

    Every transaction — regardless of tier or amount — normalises into one ledger tagged by tier, method, acquirer and currency.

Industry relevance

Built for licensed merchants running fair-pricing programmes

topropay's sliding-scale-friendly posture targets licensed non-profits, community organisations, education providers, licensed practitioners, arts and culture venues and mission-driven SaaS operators across EU, UK, APAC and LATAM. The payment infrastructure adapts to the merchant's policy — the policy stays with the merchant.

Trust & compliance

Compliance posture across every tier and amount

One audited environment underpins the orchestration layer regardless of ticket size or tier. The sliding-scale policy sits with the merchant; the payment posture sits with the platform.

PCI DSS Level 1
Vault, switch and tokenisation are PCI DSS Level 1 service-provider components; sub-merchants inherit the posture across every acceptance channel.
SCA & PSD2
Selective EMV 3DS2 on the card path keeps European approval high on sliding-scale card payments without skipping the SCA bar.
NACHA / SEPA mandates
ACH and SEPA Direct Debit mandates captured and retained per scheme rules where the merchant offers bank-rail sliding-scale payments.
Sanctions & AML alignment
Sanctions screening on onboarding; AML monitoring tuned per merchant vertical and volume.
Programme reporting friendly
Tier-tagged reconciliation exports pair cleanly with programme reports for grantors and boards where the merchant needs to evidence a sliding-scale policy.
Licensed verticals only
Licensed non-profits, education providers, licensed practitioners and other regulated verticals supported where operating licences exist. Grey and black-market verticals are out of scope regardless of pricing model.

Ready to run a fair pricing model

Build your sliding scale on flexible payment infrastructure.

A 30-minute review covers the tier shapes relevant to your programme, whether your buyers self-select or you assign server-side, and a sandbox to test against before any commercial commitment.

Book a tier-model review Read the API docs

Frequently asked

Operator questions about a sliding scale payment system on topropay

Definitions, policy-vs-platform boundaries, tier switches, refund mechanics and programme-reporting considerations for a sliding-scale flow.

  1. 01

    What does 'sliding scale payment system' mean on topropay?

    A sliding scale payment system on topropay is the payment infrastructure a merchant uses to accept variable amounts — usually because their pricing follows an income-based, tiered or pay-what-you-can policy. topropay provides the checkout, authorise endpoint, vault tokenisation, recurring engine and reconciliation feed; the merchant defines and owns the actual sliding-scale policy.

  2. 02

    Does topropay set the sliding scale for me?

    No. The sliding scale itself — the income bands, tier prices or self-declared levels — is set by the merchant according to their programme, mission or regulatory obligations. topropay's role is to make it easy to accept any amount the merchant asks the buyer to pay, and to keep it all under one reconciliation feed.

  3. 03

    How is a sliding scale different from ordinary variable pricing?

    Ordinary variable pricing means the merchant charges different amounts for different services or SKUs. A sliding scale is a specific pricing policy where the same service is offered at different prices to different buyers, typically based on ability to pay. Payment-side infrastructure looks the same for both; what changes is the policy the merchant applies before calling the authorise endpoint.

  4. 04

    Can I offer tiered subscriptions as part of a sliding scale?

    Yes. Tiered subscriptions are the most common shape. The merchant defines the tiers (e.g. supporter €5/month, standard €15/month, patron €30/month); the buyer picks one; topropay's recurring engine handles renewals and retries on the chosen tier. Tier switches happen against the same vault token without re-entering card details.

  5. 05

    Can buyers change tiers later?

    Yes. Tier changes are a dashboard-driven or API-driven update against the vault token. The next renewal charges at the new tier; the historical settlement rows keep their original tier metadata so reporting stays accurate.

  6. 06

    What about pay-what-you-can (PWYC)?

    Pay-what-you-can is a special case of sliding scale where the buyer enters an amount directly rather than picking a tier. The hosted checkout supports a variable-amount field with an optional minimum floor. Downstream — authorise, vault, reconciliation — behaves the same as a fixed-price checkout.

  7. 07

    How does the system handle partial payments?

    Partial payments run against a running balance identified by a buyer identifier or invoice ID. Each contribution creates its own settlement row tagged with the parent balance; the merchant's dashboard shows the outstanding remainder and the cumulative history. Useful for scale-of-service billing where buyers contribute over time.

  8. 08

    Can I run an installment payment plan on top of a sliding scale?

    Yes. An installment payment plan splits a single balance into scheduled installments; each installment charges the vault token on its due date. The engine is the same as recurring subscription billing; the difference is a fixed number of scheduled charges rather than an open-ended renewal.

  9. 09

    Do buyers need to see the sliding scale on the checkout?

    That's a merchant decision. Some merchants surface all tiers to the buyer and let them self-select; others determine the tier server-side (based on membership, sign-up flow or income verification) and pass the amount silently. topropay supports both patterns through the same authorise endpoint.

  10. 10

    How is a sliding scale reported for finance and programme purposes?

    Each settlement row carries the buyer identifier, chosen tier (or sliding-scale amount) and standard metadata (method, acquirer, currency). Finance-side reports roll up by tier for total revenue; programme reports split by tier for stakeholders, boards and grantors where evidencing the policy is required.

  11. 11

    Are refunds handled the same across tiers?

    Yes. Refunds run against the vault token that carried the original transaction, refunding the exact amount charged at that tier. Operator-side refund controls require reason codes and log every event with actor identity and timestamp for audit.

  12. 12

    Is a sliding-scale setup complex to implement?

    The payment-side implementation is straightforward: one authorise endpoint that accepts any amount, one vault token that persists across tiers, one recurring engine for tiered subscriptions. Complexity usually lives on the merchant side — defining the tiers, mapping buyers to tiers, and reporting outcomes. topropay's job is to keep the payment infrastructure simple so the merchant can focus on the policy.

  13. 13

    Which verticals typically run sliding-scale pricing?

    Non-profits, community memberships, education providers, licensed wellness and therapy practices, arts and culture venues, and early-stage SaaS platforms with support-us tiers all commonly run sliding-scale pricing. topropay supports each of these when the operator holds the relevant operating licence for their vertical.

  14. 14

    Is a sliding-scale checkout available in all supported markets?

    Yes. Variable-amount and tiered-subscription flows are available wherever topropay's connected acquirer panel supports the merchant's methods — EU, UK, APAC and LATAM as a baseline. A 30-minute review confirms method availability and any per-market considerations before commitment.

  15. 15

    How does the platform handle sensitive-data considerations for a sliding scale?

    topropay handles payment-side data (PAN, card metadata) inside the PCI DSS Level 1 vault. Sensitive-attribute data the merchant might collect to determine the tier (income declarations, membership status, benefit eligibility) stays on the merchant's side under the merchant's own data-protection obligations. topropay does not process that policy-side data on the merchant's behalf.

Related

Related on the topropay platform