Skip to main content

Override Amount Best Practices for Merchants

Choosing between FIXED and VARIABLE amount types is not just a technical decision — it directly affects payer trust and checkout conversion. A FIXED subscription sets a clear, predictable expectation at enrollment. A VARIABLE subscription gives you operational flexibility to charge different amounts each cycle, but shifts the burden of communication and transparency entirely to you. Getting this balance wrong increases chargeback risk, payer confusion, and involuntary cancellations.

Scenario Comparison​

ScenarioWhen to UseConversion / UX ImpactOperational FlexibilityRecommended Setup
Truly VariableUsage-based billing, consumption metering, variable service tiersModerate risk — payers need proactive communication each cycleHigh — full amount control per cyclesubscriptionAmountType: VARIABLE + subscriptionMerchantInitiation: true
Fixed Plan with Occasional OverridesStandard plans with rare adjustments (late fees, prorations, annual reindex)Low-to-moderate risk — predictable base with exceptions communicated in advanceMedium — merchant controls each cycle, deviates only when neededsubscriptionAmountType: VARIABLE + subscriptionMerchantInitiation: true (merchant enforces base amount in business logic)
Strictly Fixed (No Override)Memberships, SaaS flat fees, subscriptions with no pricing variabilityLowest risk — maximum predictability, highest payer confidenceLow — amount cannot change without canceling and re-enrollingsubscriptionAmountType: FIXED + subscriptionMerchantInitiation: false
Fixed Currency ≠ Fixed BRL Amount

If you set subscriptionAmountType: FIXED with a foreign currency (e.g., USD), the BRL amount charged to the payer will vary each cycle due to FX conversion at execution time. From the payer's perspective, this behaves like a VARIABLE subscription. Communicate this clearly at enrollment, or consider pricing in BRL to guarantee amount predictability.

Truly Variable​

When this is the right choice​

Your billing model is inherently usage-driven. The charged amount differs materially each cycle based on consumption, seat count, data volume, or a similar metric that cannot be determined in advance.

Advantages​

  • Full per-cycle amount control via the Create Charge API.
  • Supports cross-currency (FX) scenarios without manual conversion.
  • Works well for platforms with metered billing engines.

Risks​

  • Payers cannot predict the next charge amount at enrollment.
  • Unexpected amounts trigger disputes and involuntary cancellations.
  • Higher operational overhead: your system must calculate and submit every cycle on time, respecting PIX Automático's Lifecycle Windows.

Merchant Communication Best Practice​

State the billing logic explicitly at enrollment: what drives the amount, the minimum charge (subscriptionMinimumAmount), and how the payer will be notified before each debit. Never let the first variable charge be a surprise.

Practical Example​

A cloud storage platform charges BRL per GB used monthly. At enrollment, the payer sees: "Your monthly charge is calculated based on storage used. You will receive an email with the exact amount 5 business days before each billing date." Each cycle, the merchant calculates usage, notifies the payer, and submits the amount via the Create Charge API within the scheduling window.

Fixed Plan with Occasional Overrides​

When this is the right choice​

Your plan has a standard recurring amount, but you need the ability to apply one-off adjustments — annual price reindexing, late payment penalties, prorated charges for plan changes, or exceptional discounts.

Advantages​

  • Predictable base amount builds payer trust.
  • Flexibility to adjust without canceling and re-enrolling.
  • Easier reconciliation: the base amount is consistent; exceptions are documented and communicated.

Risks​

  • If overrides happen frequently, payers begin to perceive the plan as variable — eroding trust even if each adjustment is legitimate.
  • Implementing a fixed plan as VARIABLE without clear merchant-side guardrails can cause accidental amount drift.
  • Missing the PIX Automático scheduling window on a cycle with an override means the payment cannot be processed for that cycle.
Perceived Inconsistency

Merchants who operate a fixed-priced plan under subscriptionAmountType: VARIABLE must enforce the base amount in their own business logic. Sending irregular amounts without prior communication — even small ones — signals inconsistency to the payer and reduces conversion on renewals.

Merchant Communication Best Practice​

Communicate any override at least 5 business days before the due date. Include the reason, the calculation method, and the exact amount. For penalties and interest, disclose the applicable rate at enrollment — do not introduce new fee structures after the subscription is active.

Practical Example​

A gym charges a flat BRL 99/month membership. Once a year, it applies a price reindex of up to 10% based on inflation (IPCA). The merchant sets up the subscription as VARIABLE + merchant_initiation: true, submits BRL 99 every month, and on the adjustment cycle submits BRL 108.90 — after sending an email and in-app notification 7 days prior explaining the reindex.

Strictly Fixed (No Override)​

When this is the right choice​

Your pricing model is fully predictable. The same amount is charged every cycle with no exceptions. This covers most SaaS flat-fee plans, content memberships, and access-based subscriptions.

Advantages​

  • Engine-driven automation: no per-cycle API calls required after enrollment.
  • Maximum payer confidence — the authorized amount at enrollment is exactly what will be debited every cycle.
  • Lowest operational overhead and lowest dispute rate.

Risks​

  • Any pricing change requires canceling the active subscription and creating a new enrollment — the payer must re-authorize via their banking app.
  • Cannot accommodate prorations, late fees, or discounts within the same subscription agreement.

Merchant Communication Best Practice​

Emphasize the fixed amount prominently during the enrollment flow. When a price change is necessary, notify payers well in advance and frame the re-enrollment as a required step to continue the service — not as a downgrade or penalty.

Practical Example​

A SaaS tool charges BRL 49/month. The merchant sets subscriptionAmountType: FIXED, subscriptionAmount: 49.00, subscriptionAsset: BRL, and subscriptionMerchantInitiation: false. The Billing Engine handles all scheduling, execution, and retry logic automatically. No per-cycle API calls are needed.

When any deviation from the expected amount occurs — whether a reindex, late fee, interest, or promotional discount — follow these practices to protect conversion and payer trust.

PracticeGuidance
Prior Notice WindowNotify the payer at least 5 business days before the adjusted charge date. For annual reindexes or significant increases, extend to 15–30 days.
Reason and CalculationState clearly why the amount changed and how it was calculated. Example: "Annual IPCA reindex of 4.83% applied to your BRL 99.00 plan: new amount is BRL 103.78."
Predictable Limits / CapsWhere possible, define maximum adjustment caps at enrollment (e.g., "Annual reindex capped at official IPCA rate"). This sets payer expectations and reduces disputes.
Historical LogMaintain a merchant-side log of all amount changes per subscription — date, previous amount, new amount, reason. This is critical for dispute resolution and audits.
Payer Notification TemplateSend a short, clear message through your primary communication channel before each adjusted charge.

Suggested payer notification template:

Subject: Update to your [Plan Name] billing amount

Hi [Name],

Your next [Plan Name] charge on [Date] will be [Currency] [Amount].

Reason: [brief reason, e.g., "Annual price reindex based on IPCA (4.83%)"]
Previous amount: [Currency] [Previous Amount]

No action is needed. If you have questions, contact us at [support link].

[Merchant Name]

Common Mistakes to Avoid​

  • Using VARIABLE for a fixed-price plan without enforcing the base amount in business logic — leads to accidental amount drift and payer confusion.
  • Pricing in foreign currency without disclosure — payers enrolled in a USD-denominated PIX Automático subscription will see a different BRL amount every cycle due to FX conversion, which they did not expect.
  • Missing the scheduling window on an override cycle — if the merchant-submitted amount is not sent within the PIX Automático scheduling window (dueDate - 8 days to dueDate - 2 days), the charge cannot be processed for that cycle.
  • Introducing new fees post-enrollment without communication — applying penalties, interest, or new charges not disclosed at enrollment exposes the merchant to disputes.
  • Treating re-enrollment as minor friction — a FIXED subscription requiring a plan change forces the payer to re-authorize in their banking app; under-communicating this step causes drop-off and voluntary cancellations.
  • Sending override amounts with no reference_id — omitting reference_id on override cycles makes reconciliation and dispute resolution significantly harder.
  • Batching multiple adjustments silently — combining a late fee, a reindex, and a proration into a single cycle without itemizing each charge in the payer notification leads to confusion and chargebacks.

letpay Recommendation​

Your ScenarioRecommended Approach
Usage-based, metered, or genuinely variable billingTruly Variable — use VARIABLE + merchant_initiation: true. Invest in payer communication infrastructure before going live.
Standard flat-fee plan with predictable rare exceptions (annual reindex, late fees)Fixed with Occasional Overrides — use VARIABLE + merchant_initiation: true, enforce the base amount in your business logic, and override only with prior notice.
Fully fixed pricing, no exceptions anticipatedStrictly Fixed — use FIXED + merchant_initiation: false. Let the Engine drive the lifecycle and minimize operational overhead.

When in doubt, start with Strictly Fixed. It has the lowest operational risk, the highest payer trust, and requires the least ongoing maintenance. Migrate to an override model only when your business logic demonstrably requires it.