Payments live outside the CRM
Sales works in Salesforce, finance works in the gateway portal, and the two are joined by a monthly export. Nobody can answer "has this account paid?" without leaving the record.
ChargeOn brings payment processing and orchestration inside Salesforce. Installing it is the straightforward part — the value sits in the architecture around it: which gateway takes which currency, what happens the moment a card declines, how recurring schedules are governed, and how every transaction reconciles back to the record it belongs to. We design that architecture, configure ChargeOn against it, and stay through the first collection cycles.
Trusted by 500+ organizations — including subscription, services and high-volume billing teams building their revenue operations on Salesforce with Twopir Consulting.
ChargeOn Delivery Capabilities
Almost nobody loses money on the payments that succeed. Revenue leaks at the edges — the decline nobody followed up, the renewal that silently lapsed, the invoice that was paid but never matched. Those edges are an architecture problem, not an effort problem.
Sales works in Salesforce, finance works in the gateway portal, and the two are joined by a monthly export. Nobody can answer "has this account paid?" without leaving the record.
When a single processor handles every region and currency, its outage is your outage and its decline rate is your decline rate. There is no second path for the transaction to take.
A decline becomes a task, then a reminder, then a forgotten row in a spreadsheet. Without a retry and dunning cadence, recoverable revenue ages out simply because nobody had capacity that week.
Subscription and instalment schedules get maintained by whoever remembers them. Upgrades, pauses and mid-term changes each become a small act of data entry with a matching chance of error.
Teams selling across regions route everything through whichever processor was set up first, absorb avoidable conversion cost, and reconcile in a currency the ledger was never built for.
Numbers read over the phone onto a notepad, pasted into a case comment, kept in an attachment. Every one of those is compliance exposure that a tokenized flow removes outright.
ChargeOn is a Salesforce-native payment processing and payment orchestration application, published by Cyntexa on the Salesforce AppExchange. It lets a team take instant, scheduled and recurring payments from inside Salesforce across 20+ connected payment gateways, route each transaction to the right processor, recover failed and overdue payments automatically, and keep every transaction, refund and payment method on the Salesforce record it belongs to.
It is worth being precise about the category, because the name invites confusion: ChargeOn is a payments and billing application. It is not a document-generation or contract- automation tool. If your requirement is templated documents, that is a different product and a different conversation — and one we are happy to have.
ChargeOn fits organizations that already run revenue on Salesforce and are held back by how money is collected rather than by how deals are tracked: subscription and instalment billing, invoice collection, multi-region payments, and any team whose finance function reconciles by export. It is a weaker fit if Salesforce is not your system of record for customers and contracts, or if your payment volume is low enough that a single gateway portal genuinely covers it.
Product capabilities on this page are drawn from the vendor's own documentation — see the ChargeOn listing on Salesforce AppExchange.
These are three separate pieces of work with three different scopes and price points. Most teams need one of them, not all three — so it is worth knowing which conversation you are in before anyone writes a statement of work.
A first live payment flow, properly architected. For teams adopting ChargeOn and wanting it right the first time rather than iterated into shape over two quarters.
For teams already running ChargeOn who are not getting what they expected from it — usually because routing, retries and schedules were left at their defaults.
When the requirement goes past what configuration reaches: customer-facing payment experiences, agent actions, and connections into systems outside Salesforce.
Every capability below is part of the ChargeOn application. What varies between a good and a poor implementation is which of them you turn on, in what order, and with what rules behind them.
One-click card, ACH and e-check collection from the record a rep or agent is already looking at. Removes the "I'll send you a link later" gap where deals go quiet.
Subscription, instalment and retainer billing at any frequency from weekly to annual, governed by schedule rather than by whoever remembers to raise the charge.
Record-aware links a customer pays through directly. The route to take money over the phone or by email without anyone reading card numbers aloud.
Each transaction goes to the processor that suits its currency and region, with a fallback order behind it — so one gateway's bad day is not a revenue event.
Reminder, retry and dunning workflows that recover overdue, missed and failed payments on a cadence you set once, with live status instead of a chase list.
Hold funds at order, release them at fulfilment, void cleanly when something changes. Essential wherever a commitment and a delivery are days or weeks apart.
Full and partial refunds raised against the original transaction, so the credit is traceable to what it reverses rather than appearing as an unexplained outflow.
Collection in the currency the customer actually holds, with daily rate updates, and gateway selection that follows the region rather than fighting it.
Offline payments recorded against the Salesforce record so the total collected is the real total. Matters for field service, branch operations and any counter sale.
Conversational handling of payments, methods and refunds inside Salesforce, with human confirmation on the action — useful where staff work in a service console, not a billing screen.
Payment initiation from outside Salesforce — another application, a portal, or an external AI tool — while the rules and records stay in one governed place.
Card and bank details held as tokens rather than as data in your org, which is what keeps compliance scope contained as payment volume and headcount grow.
Because ChargeOn is native, it reads and writes Salesforce data directly rather than through a middleware hop. That is an advantage and a responsibility: the data model has to be right, because payment records will be attached to it for years. Here is what connects to what, and which way the data moves.
| System | Business purpose | Direction |
|---|---|---|
| Salesforce core objects | Accounts, Contacts, Opportunities, Orders, Invoices and custom billing objects supply the amount, the currency, the payer and the record a payment settles against. | Salesforce → ChargeOn |
| Payment gateways | Stripe, Adyen, Authorize.net, PayPal, Checkout.com, Global Payments, NMI, Shift4, Razorpay and other regional acquirers execute the transaction and return its result. | Two-way |
| Salesforce Flow & automation | Triggers collection at the right moment in a process — order confirmed, renewal due, milestone reached — and reacts to the outcome with tasks, alerts and stage changes. | Two-way |
| Accounting & ERP | NetSuite, QuickBooks, Xero or Sage receive settled payment and refund data for the ledger, so finance closes from one set of numbers instead of reconciling two. | ChargeOn → finance |
| CPQ, subscription & billing | Quote, contract and subscription records define what is owed and on what schedule; ChargeOn is the mechanism that actually collects it. | Billing → ChargeOn |
| Experience Cloud portals | Customers view balances, update a stored payment method and settle invoices themselves, which removes a large share of inbound payment admin. | Two-way |
| Agentforce | Service and sales staff process payments, manage methods and locate refunds conversationally, with confirmation required before an action commits. | Two-way |
| External systems via Headless 360 | An ecommerce front end, a partner application or an external AI tool initiates payment through the same rules and lands in the same records. | External → ChargeOn |
| Reporting & data warehouse | Collection rate, decline and recovery reporting, days-sales-outstanding and gateway performance, available to leadership without a finance export. | ChargeOn → reporting |
A focused single-gateway implementation is typically a 4–6 week engagement. Multi-entity, multi-currency or portal work runs 8–14 weeks. What moves that number is rarely ChargeOn — it is data quality, how many gateways and entities are in scope, and how quickly finance can approve test transactions.
We map every way money currently arrives — invoice, subscription, deposit, phone, counter, portal — and who touches each one. Most scope surprises are payment routes nobody mentioned because they felt too small to matter.
We audit the existing org and gateway setup: decline rates, where card data is being stored today, which automations already touch billing, and what finance is manually correcting each month. This is where the business case usually becomes concrete.
We decide which object payments attach to, how entities and currencies are separated, which gateways are primary and which are fallback, and what the permission model for refunds and voids looks like. This is the document the rest of the build is measured against.
Installation, licence allocation, gateway credentials in sandbox first, payment methods, record pages and permission sets. Nothing touches production credentials until a test transaction has completed end to end in a sandbox.
Routing and fallback rules, retry logic, dunning cadences, recurring schedules, payment-link generation, reminder content and the Flow automation that triggers collection at the right process moment. This stage is where the outcome is actually won or lost.
Only where configuration genuinely cannot reach: portal payment experiences, Agentforce actions, Headless 360 endpoints, and the accounting or ERP connection that lets finance close from one set of numbers.
Gateway test mode across every payment type, deliberate failure and fallback testing, refund and partial-refund paths, dunning sequences run against the clock, permission testing per role, and finance signing off that the reconciliation output is usable.
Role-based training for the people who take payments and the people who reconcile them, a controlled cutover, then a review after the first full billing cycle — because decline and recovery patterns only become visible once real volume runs through.
Grouped by how the money arrives, not by sector. Two organizations in different industries with the same collection pattern need very similar builds — and two in the same industry often do not.
SaaS, technology and media teams charging monthly or annually. The work is schedule governance, mid-term changes, and a retry cadence that stops involuntary churn at the card, not at the customer.
Professional services and manufacturing chasing B2B invoices. Payment links on the invoice, automated reminders before and after due date, and days-sales-outstanding that leadership can actually see.
Rent, deposits, holding fees and management charges against the property, tenancy or deal record — so a portfolio view of what has been collected exists without a managing agent's spreadsheet.
Non-profits running one-off appeals and regular giving. The priority is recovering lapsed recurring gifts quietly and keeping donor payment methods current without a phone call.
Healthcare, life sciences and membership bodies taking co-pays, plans and dues. Tokenized methods and self-service balances matter more here than anywhere, for both compliance and call volume.
Higher education and ed-tech splitting a fee across a term or year. Instalment schedules, partial payments, and recovery that does not disenrol a student over a single expired card.
Service, trades and travel businesses collecting at the point of work, including cash and cheque recorded against the job — so the day's takings reconcile without a paper round-trip.
Any team selling across borders. Local acquiring where it reduces decline rates and cost, separated entities and ledgers, one reporting view across all of it.
We do not publish a percentage against these, because the honest answer depends entirely on where you start — a team with a 4% decline rate and a team with a 12% one do not have the same upside. What we will do is baseline yours during the assessment, then measure against it.
Reminders, retries and receipts stop being someone's weekly task list. The people who were chasing payments move to the exceptions that genuinely need a human.
Routing by currency and region, plus a fallback path and a retry cadence, converts a share of declines that previously just became aged receivables.
Collection triggered at the process moment it is due, with a link the customer can act on immediately, shortens the gap between work delivered and money received.
Every transaction is attached to the record it settles, so month-end matching stops being a reconstruction exercise between a gateway export and a CRM report.
Tokenized collection removes the informal places card details accumulate — notes, attachments, call logs — which is the exposure that grows quietly with headcount.
Collection rate, recovery rate, decline reasons and gateway performance become standing reports leadership reads, rather than questions finance answers on request.
We work with growing, mid-market, and enterprise organizations that need help with complex CRM implementations, integrations, and business system challenges. Payments is one of the places that complexity shows up fastest, because it is where the CRM meets money that has to balance.
Before anything is installed we map how money arrives today and where it stalls. The configuration then follows a decision we can both defend — rather than the app's defaults becoming your process by accident.
Most of what teams are quoted as custom development is declarative in ChargeOn. We tell you which side of that line your requirement sits on during scoping, in writing, because that boundary is most of the difference in cost.
A payment implementation that sales likes and finance cannot reconcile has failed. Ledger structure, entity separation and refund controls are part of our design stage, not a problem discovered at month-end.
Our team has delivered gateway integrations, recurring billing, trust-accounting workflows and finance synchronisation on Salesforce across several payment applications. The failure modes are familiar to us.
Decline patterns, recovery rates and reconciliation gaps only appear under real volume. We review after the first full cycle and tune the routing and dunning rules against what actually happened.
We will be straightforward about this: the engagements below are Salesforce payment, billing and integration projects delivered on other applications — not ChargeOn implementations. They are the reason we understand the architecture, and we would rather show you real adjacent work than a ChargeOn case study we cannot evidence. Ask us on the call and we will walk you through the closest comparable build in detail.
Our established Salesforce payments practice — gateway integration, recurring billing, automated collections and finance synchronisation — delivered on Chargent for teams whose requirements suited it. The architecture work is the same discipline a ChargeOn build needs.
See Our Chargent Payment ServicesA quote-to-revenue engagement connecting Salesforce CPQ with the surrounding systems that price, invoice and collect. The same integration boundaries, data-model decisions and finance alignment that determine whether a ChargeOn implementation holds up at month-end.
Read The CPQ Case StudyThe pillar page — what ChargeOn is, how the payment layer works, and which capabilities matter before you evaluate a partner.
Read the guideThe sibling payment application we also implement. Worth comparing if you have not yet committed to a platform.
Compare the optionsHow subscription billing platforms connect to Salesforce — useful background if recurring revenue is your primary motion.
Read the integration guideHow our retained support works once ChargeOn is live — tuning, monitoring and the next stage of build.
See support optionsA ChargeOn implementation has four substantial parts. First, mapping how money currently arrives and deciding which Salesforce object each payment type should attach to. Second, installing ChargeOn and connecting your payment gateways, in a sandbox before production. Third, building the rules that make it useful — routing by currency and region, gateway fallback, retry and dunning cadences, recurring schedules and payment links. Fourth, testing every path including deliberate failures, then training the people who take payments and the people who reconcile them. The installation is the shortest of the four. The rules and the data model are what determine whether the implementation holds up.
A focused implementation with one gateway, one entity and one or two payment types is typically four to six weeks. Multi-entity, multi-currency, portal or ERP-integrated work generally runs eight to fourteen weeks. What extends a timeline is rarely the application itself — it is data quality in the records payments will attach to, the number of gateways and legal entities in scope, and how quickly your finance team can approve test transactions and sign off that the reconciliation output is usable. We give you a scoped range after the assessment stage, not before it.
Configuration covers more than most teams expect. Gateway routing, fallback order, retry and dunning cadences, recurring schedules, payment links, reminder content, notifications and the surrounding record automation are all achievable through point-and-click setup plus Salesforce Flow. Custom development becomes necessary in four situations: a payment experience your customers use directly rather than your staff, logic that has to run against volumes or rules the packaged automation cannot express, a system outside Salesforce that must initiate or receive payment data, and behaviour that must differ per business unit within one org. If a proposal quotes custom code for routing rules or dunning sequences, ask why.
Usually not. ChargeOn connects to more than twenty payment gateways, including Stripe, Adyen, Authorize.net, PayPal, Checkout.com, Global Payments, NMI, Shift4 and Razorpay, so in most cases your existing processor and merchant agreements stay exactly as they are. The more common recommendation runs the other way: teams collecting across several regions often benefit from adding a second gateway for local acquiring, because decline rates and conversion costs differ by market. That is a commercial decision we help you model during the assessment — it is not a prerequisite for going live.
Several mature applications collect payments natively in Salesforce, and the sensible ones to shortlist alongside ChargeOn are Chargent and Blackthorn Payments. They overlap substantially on the fundamentals — cards and ACH, recurring billing, refunds, tokenization. ChargeOn differentiates on orchestration across a broad gateway set, automated collections, and its Agentforce and Headless 360 support for conversational and external payment initiation. The right answer depends on your gateway mix, how much of your volume is recurring, whether customers need to self-serve, and your licence budget. We implement more than one of these and have no reseller incentive, so we will tell you if your requirements point somewhere other than ChargeOn.
To be precise: Twopir Consulting is a Salesforce Partner, and we implement ChargeOn. ChargeOn is published by Cyntexa, and we do not hold or claim a Cyntexa reseller or partner badge. In practice that is an advantage for you — we earn nothing on the licence, so our recommendation on whether ChargeOn is the right application for your requirements is not influenced by a commission. You buy the licence directly from the vendor on the AppExchange, and you engage us for the architecture, configuration, development and support around it.
The ChargeOn licence is bought from the vendor, and its AppExchange listing has shown pricing starting around 3,500 US dollars per company per year covering twenty users, with a free trial available — confirm the current figure on the listing, since vendor pricing changes. Our implementation fee is separate and scoped to the work, which is why the configuration-versus-code boundary matters so much to your total cost. On support: yes. Most clients move onto a retained arrangement after go-live, because routing and dunning rules are worth tuning against real decline and recovery data, and because payment requirements change whenever you enter a new market or launch a new billing model.
Bring us your current collection process and your decline and ageing numbers. We will tell you what ChargeOn would change, what is configuration and what is custom development, and what the work would realistically take — before anyone writes a statement of work.
Speak with a team that architects payment operations, not just installs apps