When a software company expands internationally, “localization” often starts with translation, currency display, and a new payment option. Those changes matter, but they are not the whole product. A local operator may need a different onboarding path, support arrangement, or way to package the service—not just the same interface in another language.
Bolten, a Brazilian platform that serves agency and service partners, offers a case for examining these decisions. Its public materials describe partner-created branded projects, two collection models, and support responsibilities divided between the partner and platform. These are vendor descriptions, not the result of an independent product benchmark or a live account test. Bolten’s documentation was; payment and product terms can change. These choices frame questions for global software teams. Brazil offers a case study to examine, not a formula to copy.
Establish local context before sizing the opportunity
Brazil has a large connected population. DataReportal’s Digital 2026: Brazil, published at the end of 2025, estimated 185 million internet users at the end of 2025 and 150 million social-media user identities in October 2025. DataReportal cautions that social-media identities may not equal unique people. These figures describe potential digital reach; they do not show how many businesses will buy a particular software product, what they can pay, or which features they need. (DataReportal — Digital 2026: Brazil)
Payment behavior gives another piece of context. The Central Bank of Brazil reported that Pix represented 47% of the number of payment transactions (excluding cash) in the fourth quarter of 2024. That is evidence of Pix’s scale in the national payment mix, not evidence that every SaaS customer prefers Pix or that a specific software platform supports it. A product team should treat country-level patterns as hypotheses to test with its intended buyers.
Make the commercial relationship a product decision
Bolten’s current 70/30 guide describes a seven-day trial, Stripe checkout for new eligible Brazilian partners, and an automatic 70% share of payments to the partner. Its Repasse guide says the partner pays minimum prices for the tools in use and sets the client price. The FAQ still describes Pagar.me, which the updated 70/30 guide labels a legacy route for clients who have not migrated. This mismatch matters when assessing cash timing: Stripe follows its own card-settlement and payout schedule, so the FAQ’s older transfer estimate should not be generalized. Verify account-specific eligibility, fees, settlement, and terms. (Bolten — 70/30 billing; Bolten — Repasse billing)
The existence of two routes is the design lesson. One puts more of the payment relationship with the platform; the other leaves the partner to package and collect for a broader service. Neither automatically creates a good margin or aligns incentives. The 70% figure is gross before the partner’s labor, taxes, service costs, payment conditions, and client support. The reseller arrangement shifts a different set of pricing and collection responsibilities to the partner.
For global SaaS teams, the question is broader than “monthly subscription or revenue share?” Ask who sets the client price, who collects the money, who handles failed payments, which costs vary by usage, and who carries the relationship when a customer wants to leave. These choices affect the product’s economics and the work users must perform around it.
Treat local payment methods as infrastructure with limits
A payment method can shape onboarding, checkout, reconciliation, refunds, and support. The Central Bank’s Pix statistics show why a product team in Brazil should investigate Pix as part of local payment design. But national use statistics cannot answer implementation questions: which providers support the intended flow, what settlement or refund process applies, what records an agency needs, or which methods each customer expects. (Central Bank of Brazil — Payment methods used in 2024; Central Bank of Brazil — Pix statistics dataset)
Bolten’s updated 70/30 guide describes a Stripe checkout for new eligible partners and says the customer selects a payment method available for the region; it does not establish Pix availability for a particular account. The FAQ still describes a Pagar.me card checkout, which the updated guide labels legacy. Evidence about Brazil’s payment ecosystem must not be presented as a feature of either route. Confirm the actual checkout and account terms before describing a payment method to customers.
Global products can apply the same discipline in every region. Map the full payment journey from the user’s first price display through collection, settlement, refunds, receipts, and support. Localize the steps that create real friction; do not add a payment badge simply because it is familiar in a market.
Design partner responsibilities instead of hiding them
Bolten describes the partner as the first line of support for end clients, with the platform available to the partner for training, questions, and technical issues. Its model links configurable software to a service operator who onboards clients and handles their initial questions. This may suit an agency that already provides implementation and ongoing service. It may be a poor fit for a reseller that expects the platform vendor to support every end user directly. (Bolten — Partner FAQ)
That is not a minor sales detail. The support model changes what the product is: who trains the customer, who explains an unfamiliar workflow, who receives a complaint, and who coordinates an escalation. If the vendor leaves first-line support to a partner, the partner needs enough documentation, time, and authority to do it. The software price alone will not describe the complete cost of delivery.
Before launch, a global product team can map the responsibility boundary. List which party handles account creation, configuration, billing questions, technical incidents, data requests, and cancellation. Show that boundary to a real prospective user and ask where they would go for help. The answer may vary by segment and sales model.
Separate what transfers from what must be retested
Some design questions travel well across borders: who owns the customer relationship, where support starts, which costs change with usage, and whether customers can understand the next step. Their answers do not transfer automatically. Local payments, communications channels, account rules, pricing, and legal obligations must be validated in each market and for each product configuration.
A practical review for a new region can begin with five questions:
- Payment: Which methods do intended customers actually use for this category and price point? What does the product support today?
- Workflow: Where do customers first discover the service, request help, and receive a response? Which steps currently require manual work?
- Support: Who serves as the first contact, and can that party resolve the common issues customers face?
- Economics: Who sets the price and collects it? Which costs, fees, and labor scale with each account?
- Evidence: Which conclusions come from official data, vendor documentation, customer research, and a live product test?
Record those sources separately. A broad population or payment statistic can establish context. Vendor documentation can establish what the vendor says its product supports. Interviews, account tests, and operating data are needed to establish whether the offer fits a specific customer group.
Apply the Brazilian case within its evidence limits
The public Bolten materials illustrate a partner-oriented commercial model, with separate routes for direct client billing and partner-paid resale, plus partner-first support. They show product decisions worth studying because they connect software to a service operator’s work. They do not prove that revenue share is superior to subscriptions, that a partner model scales with no trade-offs, or that one product configuration represents Brazilian businesses as a whole.
The broader lesson is modest and more transferable: international expansion works better when teams examine the relationships around the software as closely as the interface. Price, payment, onboarding, support, and responsibility are part of product design. A local market can reveal questions a global roadmap missed; only local evidence can tell a team which answers fit.
