Chargent puts card, ACH and recurring payments inside Salesforce. Getting it live is configuration; getting it to match how your business actually bills, retries, refunds and reconciles is architecture. Twopir Consulting designs the payment data model, connects your gateway, automates collections, and keeps cardholder data out of your org. Implementation, customization, integration and ongoing Chargent support.
Trusted by 500+ organizations — including subscription, clinical and professional-services businesses collecting payments inside Salesforce with Twopir Consulting.
Chargent Delivery Capability
Most revenue teams have the CRM side solved. The payment side still runs on a gateway portal in another browser tab, a spreadsheet of failed charges, and a monthly reconciliation nobody enjoys. Every one of these is a systems problem, not an effort problem.
A rep closes the deal in Salesforce, then logs into a separate gateway portal to key the card in by hand. The transaction never links back to the opportunity, so nobody can answer "did this customer pay?" without opening two systems.
Someone creates a text field for the card number "just for now". The moment raw cardholder data lands in the org, the whole Salesforce instance is in PCI audit scope — including every integration, sandbox and report that can read it.
A card expires, the monthly charge declines, and nobody notices until the customer calls or the renewal report looks wrong. Involuntary churn is revenue you already won and then lost to a payment-method problem.
Gateway settlement reports, Salesforce records and the accounting system each tell a slightly different story. Finance spends days matching them instead of closing the books, and disputes get investigated from screenshots.
Every payment needs a staff member on a phone call. There is no secure link to email, no saved payment method, and no portal where a customer can settle a balance at 9pm without occupying somebody's afternoon.
Two legal entities, three currencies, a surcharge rule in one state and not another — and one gateway record trying to carry all of it. Without a designed payment data model, every new business unit becomes a workaround.
Chargent is a Salesforce-native payment application from AppFrontier that lets teams take credit card and ACH payments, run recurring billing, and automate collections directly from Salesforce records. It connects your own merchant account and payment gateway to Salesforce without middleware, and it stores gateway tokens rather than card numbers, so the org keeps sensitive payment data out of its own fields.
The practical difference is where the work happens. Instead of a rep leaving Salesforce to key a payment into a gateway portal, Chargent puts a payment interface on the record they are already looking at — an Account, an Opportunity, a Case, or a custom object built for your process. The transaction, the schedule and the payment method all become Salesforce data, which means they can be reported on, automated against and audited like anything else in the org.
Chargent is a strong fit when payments are part of a relationship your team already manages in Salesforce: retainers, memberships, subscriptions, invoices, deposits, tuition, donations, service fees. It is a weaker fit when you need a high-volume anonymous checkout with no CRM context — that is an ecommerce problem, not a CRM payments problem, and we will say so on the call rather than after the statement of work. Product capabilities and current behaviour are documented in the Chargent documentation from AppFrontier. For background on why teams move payments into the CRM at all, see why native Chargent payment processing in Salesforce matters.
| Layer | What it covers | Owned by |
|---|---|---|
| The gateway | Authorization, capture, settlement, funding, chargeback handling, card-brand rules and your processing rates. | Your payment provider — Chargent connects to it, it is not a processor itself. |
| Chargent | The Salesforce-native payment objects, the payment interface on records, recurring schedules, collections automation, tokenization and the gateway connections. | AppFrontier — the licensed product and its roadmap. |
| The implementation | Payment data model, which objects transact, automation and flows, permissions, surcharge and entity rules, integrations, testing, migration, training and support. | Twopir Consulting — this is the work described on this page. |
| The outcome | Shorter time to cash, fewer failed payments left unworked, a reconciliation that closes on schedule, and payment data your leadership can actually report on. | Your business — measured against the baseline we capture in discovery. |
We are a Salesforce Partner and we implement Chargent. We are not a payment processor, we do not resell merchant accounts, and we hold no commercial interest in which gateway you choose — which is why our gateway recommendation is an architecture decision rather than a referral.
"Chargent consulting" means something different depending on whether you have not bought it yet, have had it installed for two years, or need it to do something it does not do out of the box. These are the three engagements, and the first call establishes which one you are in.
A first Chargent deployment, delivered end to end — from payment requirements through gateway connection, configuration, testing and go-live. For teams moving payments into Salesforce for the first time.
You already own Chargent and it is underperforming — collections are manual, schedules drift, failed payments go unworked, or adoption never happened. We rebuild the parts that are costing you money.
Your payment process does not fit the standard configuration. We extend Chargent using its supported developer surface — the Payments API, Flow, Apex and Lightning Web Components — without forking the managed package.
Where configuration ends and development begins. Most of what teams assume needs code does not. Taking payment on a custom object, emailing a secure payment link, running a weekly recurring charge with a stop rule, retrying a declined card on a schedule, adding a compliant surcharge, or exposing a self-service payment component in a customer portal are all configuration and declarative automation — they belong in setup and Flow, and we deliver them that way.
Development becomes the right answer when the payment behaviour itself has to change: proration rules that no schedule expresses, routing a transaction to a different gateway or legal entity based on record data, an approval gate in the middle of a charge, or a payment step inside a system that is not Salesforce. That work goes through Chargent's documented Payments API and standard Apex and Lightning Web Component patterns — never by modifying the managed package, which would break your upgrade path. It also sits inside our wider Salesforce consulting and implementation services and can be carried by ongoing Salesforce support once live. Some of it is also gated by edition: the Payments API and Automated Collections require Chargent's Growth or Enterprise edition, so we confirm licensing before designing around either.
Installing the managed package takes an afternoon. These are the decisions that determine whether the deployment still works when volume triples, a second entity is added, or the person who set it up leaves.
Chargent's payment records hub — and its relationships to Transactions, Gateways and Payment Methods — has to be mapped onto your existing objects before anything is configured, or you inherit a structure that fights every later requirement.
Chargent ships pre-built connections to 30+ gateways. Choosing between them is a business decision about rates, funding timelines, supported methods, regions and the features your process depends on — not a technical coin toss.
Recurring revenue fails on the edge cases: mid-cycle upgrades, pauses, failed first charges, end dates that should not fire. We design the schedule, frequency and stop-rule logic around your contract terms.
A declined payment should start a sequence, not a task for somebody to remember. We build the retry cadence, the dunning emails, the payment-link follow-ups and the escalation point where a human takes over.
Chargent tokenizes payment details so card numbers are held by the gateway, not in Salesforce. That only reduces your PCI scope if the surrounding configuration does not reintroduce raw data — which is a design review, not a checkbox.
Payments are events other processes should react to. We wire Chargent into the org's automation properly — record-triggered flows, scheduled jobs, notifications — and build the reporting layer finance and leadership actually use.
A payment is rarely the end of a process. It needs to reach finance, update a subscription, close a case, or unlock a service. These are the connections we design and build around Chargent.
Salesforce sends the authorization request to your own merchant account; the gateway returns a token and a result that Chargent writes back as a Salesforce transaction record. No middleware sits between the two.
A separate Chargent package connects your gateway to Salesforce Billing, so a payment taken against an invoice applies to that invoice or account balance instead of being recorded somewhere finance has to find later.
Chargent's payment component lets customers pay, save a method and view upcoming payments from your portal. Every self-service payment lands on the same Salesforce records your staff work from.
Settled transactions flow outward to QuickBooks, NetSuite, Accounting Seed or your ERP as cash receipts, so the month-end match is a report rather than a manual exercise across three exports.
REST, Flow and Apex interfaces let systems outside Salesforce request a payment, or let Salesforce automation trigger one mid-process. Requires Chargent's Growth or Enterprise edition.
Chargent's surcharging feature, powered by InterPayments, calculates and applies card surcharges inside the Salesforce transaction according to the rules that apply where the customer is.
Payment events drive the rest of the process: a successful charge advances a stage, closes a case or releases fulfilment; a decline opens a task and starts a dunning sequence.
A signed agreement should be able to trigger the first charge and the recurring schedule behind it, so contract execution and payment setup stop being two disconnected manual steps.
| Connection | Data that moves | Direction | Consumed by |
|---|---|---|---|
| Salesforce and the gateway | Authorization request out; token, approval code, decline reason and transaction result back. | Bi-directional, per transaction | Sales, support, billing |
| Chargent to accounting and ERP | Settled payments, refunds and chargebacks as cash receipts against the right customer. | Outbound, scheduled or event-driven | Finance and controllership |
| Chargent to the CRM record | Payment status, balance, next charge date and failure history on the account or opportunity. | Inbound to the record, in real time | Reps and customer success |
| Experience Cloud to Chargent | Customer-initiated payments, saved methods and updated card details. | Inbound from the portal | Billing and collections |
| External system and Payments API | Payment requests raised outside Salesforce and their results returned to the caller. | Bi-directional, on demand | Product, operations, engineering |
Six phases, one accountable team. A straightforward single-gateway implementation typically runs in weeks rather than months; multi-entity, multi-gateway or API-integrated builds take longer, and we scope that honestly before you sign anything.
We map how money actually reaches you today — who takes payments, on what, in which system, and where it stalls. This is also where we capture the baseline the project will be measured against.
We design the payment data model, decide which objects transact, and select the gateway and Chargent edition against your real requirements — methods, regions, entities, volume and the features you depend on.
Package install, gateway connection, payment interfaces on the right records, recurring schedules, collections sequences, permissions and automation — built in a sandbox, never directly in production.
Test transactions through the gateway sandbox across every path that matters: approvals, declines, partial refunds, voids, expired cards, retries and the reconciliation output finance will receive.
A controlled cutover with live-credential verification, any historical payment-method migration, and role-specific training — a rep, a billing clerk and an administrator each need a different session.
After go-live we watch what the data says: recovery rates, decline reasons, schedule drift, adoption. Chargent ships updates and gateways change their APIs — someone has to own that, and we do.
The common thread is a payment attached to a relationship your team already manages in Salesforce. These are the patterns we implement most often, and what the configuration work looks like in each.
| Scenario | The payment problem | What we configure |
|---|---|---|
| Subscription & membership billing | Recurring charges that fail silently, and renewals nobody sees coming until the revenue report moves. | Recurring schedules with stop rules, saved payment methods, expiry handling and automated retry sequences. |
| Professional services retainers | Invoices emailed as PDFs and chased by hand, with payment status living in a finance inbox. | Payment request links on the engagement record, balance visibility for the delivery team, and reminders that escalate. |
| Real estate and property operations | Deposits, application fees and recurring rent collected across several entities and bank accounts. | Multi-entity payment routing, ACH for higher-value transfers, and payment records tied to the property or lease object. |
| Healthcare and clinical services | Patient balances, co-pays and treatment plans paid in instalments across multiple visits. | Payment plans on the patient record, tokenized methods for repeat billing, and strict field-level access on payment data. |
| Nonprofit giving | One-off donations and recurring giving managed separately from the constituent record. | Recurring donation schedules, self-service giving in Experience Cloud, and receipting triggered from the transaction. |
| Inside sales and call centres | Agents leave the CRM mid-call to key a card into a gateway portal, then re-key the result back. | A payment interface on the object the agent already works from, so the charge and the record update happen once. |
| Field service and dispatch | Work completed on site but invoiced days later, with cash collection depending on an office follow-up. | Payment capture on the work order or case, mobile-friendly payment links, and automatic case closure on settlement. |
Not every payment problem belongs in Chargent. High-volume anonymous ecommerce checkout, complex usage-based metering and marketplace split payments are better served elsewhere, and we will tell you that in discovery rather than build around it. Read the Chargent payment solution overview for a broader introduction to the platform.
Payment infrastructure is one layer of a wider operating system. See how we build the rest of it for real estate and property teams, healthcare providers, nonprofit organizations, SaaS and subscription businesses, professional services and consulting firms, and law firms.
Both engagements below are Salesforce billing and payment-operations builds rather than Chargent deployments specifically. They are included because the discipline is the same — one payment data model, automated collection, and a reconciliation that closes without a spreadsheet. Each figure is scoped to the engagement that produced it.
Twopir provided Salesforce customisation and integration services to help us build a robust, compliant, and scalable legal operations platform — connecting case management, document processing, and financial systems into one unified workflow. The result was transformative for how we run case-to-cash operations.
Streamlining case-to-cash operations with Salesforce, AWS and QuickBooks.
Twopir's specialized Salesforce customization enabled efficient integration of third-party systems and streamlined administration and billing, leading to seamless financial operations and enhanced productivity. Automated mass billing and matter management minimized errors across our entire legal workflow.
A 50% efficiency gain from Accounting Seed and Salesforce integration.
Chargent sits at the intersection of CRM, finance and compliance. A partner who only knows the app will configure it correctly and still leave you with a payment process that fights the rest of your Salesforce org.
Before anything is installed we map your billing terms, entities, payment methods and the points where cash gets stuck. The configuration follows that model — which is why it survives the second business unit.
Payment automation has to coexist with the flows, Apex, validation rules and sharing model already in your org. We review those interactions as part of the build instead of discovering them during a failed charge.
We earn nothing from your processing volume. When we recommend a gateway it is because of your payment methods, regions, entities and funding timelines — and we will tell you when your current one is fine.
Tokenization only keeps Salesforce out of PCI scope if nothing in the surrounding configuration reintroduces raw card data. We audit for that explicitly, including custom fields, integrations and sandbox copies.
Chargent ships new versions, gateways change their APIs, and your billing model evolves. Ongoing Chargent support is a standing offer, not an upsell we introduce once something breaks.
Installing the managed package is the smallest part. A Chargent implementation means designing the payment data model, deciding which Salesforce objects transact, connecting and testing your payment gateway, configuring recurring schedules and collections automation, setting permissions so the right people can take and refund payments, wiring payment events into your existing flows, and training three different audiences. A straightforward single-gateway deployment typically runs in weeks; multi-entity, multi-gateway or API-integrated builds take longer.
A capable Salesforce administrator can install Chargent and take a first test payment. Bring in a Chargent consultant when the decisions get structural: several legal entities or currencies, recurring billing with real contract terms, a collections process that has to run itself, PCI scope you have to defend, or an integration with accounting or an external system. The cost of getting the payment data model wrong is a rebuild, and it usually surfaces a year later when the second business unit is added.
Chargent uses tokenization: the card number goes to your gateway, and Salesforce receives a token that can be used for future charges but carries no exploitable value on its own. That is what reduces your PCI audit scope. It only holds if the rest of the configuration respects it — a custom text field capturing a card number, an integration logging a raw payload, or a sandbox with production data will all put sensitive data back into the org. Auditing for exactly that is part of how we implement it.
Chargent ships pre-built connections to more than 30 gateways, so the decision is commercial and operational rather than technical. It turns on the payment methods you need, the countries and currencies you bill in, your processing rates and funding timeline, whether you need ACH or surcharging, and whether you already hold a merchant account worth keeping. We are gateway-neutral and earn nothing from your processing volume, so the recommendation is an architecture decision — including the recommendation to stay where you are.
Yes, through its supported developer surface rather than by altering the managed package. Chargent exposes a Payments API with REST, Flow and Apex interfaces, and payment components can be embedded in Lightning and Experience Cloud pages, which covers custom billing logic, entity or gateway routing, payment steps triggered from outside Salesforce, and bespoke customer payment experiences. Note that the Payments API requires Chargent's Growth or Enterprise edition, so licensing gets confirmed before any design depends on it.
That is one of our most common engagements. An org can be live on Chargent and still leave most of the value on the table — no retry schedule, no dunning sequence, payment requests sent by hand, recurring schedules that drift, or reporting that cannot show recovery rates. We audit the existing configuration against how you actually bill, then rebuild the collections and automation layer. Chargent's Automated Collections capability requires its Growth or Enterprise edition, which we confirm before scoping the work.
They solve adjacent problems. Salesforce CPQ and Billing handle quoting, pricing, invoicing and revenue recognition; Chargent handles the payment itself — connecting a gateway, capturing card or ACH, running recurring charges and automating collection. They are frequently used together, and AppFrontier ships a separate Chargent package for Salesforce Billing so a payment applies against an open invoice or account balance. If you have neither yet, the order of implementation depends on whether your bottleneck is producing the invoice or collecting against it.
A first conversation covers your payment methods, entities, recurring terms and where cash currently gets stuck — enough to say whether Chargent is the right answer, which edition you need, and what an implementation would actually take. No obligation to proceed.
Salesforce architects who have built payment and billing infrastructure before
