Salesforce for payments and fintech: merchants, partners and risk

Payment processors, ISOs, payfacs and B2B fintechs use Salesforce as the system of record for merchants, sales agents and partners. It tracks each application from intake through underwriting to boarding, splits residuals across agents, and routes merchant support. It should not hold card data. Processors and underwriting platforms stay the source of truth for transactions and risk decisions, while Salesforce holds the relationship, the workflow and the status.

What does a payments company actually need Salesforce to manage?

Three relationships at once: the merchant, the agent or partner who sold it, and the processor that boards it. Most payments CRMs fail because they model only the first.

A card-acceptance business has a longer chain than a typical B2B seller. An independent agent finds a merchant. The ISO packages an application. A sponsor bank and processor approve it. Then the merchant generates residual income for years, split among several parties.

• Merchants, often with many locations and more than one merchant ID per location.
• Agents, sub-agents and referral partners, each with their own split terms.
• Applications that move through intake, document collection, underwriting and boarding.
• Residual statements that arrive from processors and must be allocated back to the people who earned them.
• Support requests from merchants about statements, equipment, chargebacks and deposits.

B2B fintechs selling software or embedded payments share most of this shape. They may call agents "resellers" or "referral partners", but the structure is the same.

How should merchants, locations and accounts be modeled?

Use the account hierarchy for the legal entity and its locations, and a custom object for each merchant ID. Keep the processor's identifiers as external IDs, not free text.

A restaurant group may have one legal owner, eight locations and twelve merchant IDs across two processors. If you flatten that into one account, residual and support reporting both break. Our account hierarchies guide covers parent-child design in more depth.

• Parent account: the legal entity or ownership group that signs the agreement.
• Child accounts: each physical or online location, with its own address and contacts.
• Merchant ID record: one per processor account, linked to the location, holding status and boarding dates.
• Agent lookup: the agent of record on each merchant ID, which drives residual splits later.

Store external IDs from the processor on the merchant ID record. That makes nightly updates and residual matching reliable instead of name-based guesswork.

How do onboarding and underwriting workflows run in Salesforce?

Treat each application as a record with clear stages, required documents and an approval path. Salesforce runs the workflow; the underwriting system makes the risk decision.

A typical flow starts with intake from an agent, a web form or an internal rep. Salesforce then checks completeness before anything leaves the building.

• Intake: capture business details, owners, expected volume and the agent of record.
• Document collection: request bank letters, IDs and statements through a secure upload or the agent portal, and flag what is missing.
• Agreement signature: generate the merchant agreement and route it for e-signature.
• Internal review: route exceptions, such as high-risk categories or unusual volume, to a named approver.
• Submission: send the package to the processor or underwriting platform and record the response.
• Boarding: write back the approval, the merchant ID and any conditions.

Approval processes or Flow-based approvals handle internal sign-off. Our approval processes guide and our document generation and e-signature guide cover both patterns.

Integration with processor and underwriting systems is usually API-based. One payments ISO we worked with connected Salesforce to its processor through a custom API. Applications go to underwriting automatically, and the merchant ID comes back into Salesforce on approval.

Can agents and ISOs work in a Salesforce portal?

Yes. Experience Cloud gives agents and partners a login where they see their own merchants, submit applications and check status. Sharing rules control what each partner can see.

The payments ISO above gave more than 60 independent agents a self-service Experience Cloud portal. Agents search their merchants, submit applications and track status without emailing the back office.

Plan the portal around partner hierarchy. Master agents may need to see their sub-agents' merchants, while sub-agents see only their own. Our partner relationship management guide explains how partner accounts, roles and sharing fit together.

Portal licensing varies by user type and volume. Confirm the right partner license with your Salesforce account team before you size the rollout.

How do residuals and commission splits work?

Load processor residual files into Salesforce, match each line to a merchant ID, then apply each agent's split rules. Agents see their own statements; finance sees everything.

Residuals are recurring and layered. One merchant line can pay the ISO, a master agent, a sub-agent and a referral partner. Each split can depend on the agent's schedule and the merchant's pricing.

• A residual summary object holds one row per merchant ID per period, matched by external ID.
• Split rules sit on the agent or the agent-merchant relationship, not in spreadsheets.
• Automation calculates each party's share and creates payable lines for review.
• Unmatched lines go to an exception queue rather than being silently dropped.

That ISO added residual summary objects, automated the agent split calculations and built reporting on top. That gave agents and leadership visibility into residuals they previously could not see. Our sales commission tracking guide covers when to build this natively and when to use a dedicated tool.

How should merchant support be handled?

Use Service Cloud cases with record types for common merchant issues, routing by skill, and entitlements that escalate when a response target is missed.

Merchants call about deposits, chargebacks, terminals and statements. Each type needs different expertise and a different urgency. A chargeback with a response deadline should not sit behind a paper-roll order.

The same ISO routes merchant cases in Service Cloud, escalates them against SLA targets and posts alerts to its team chat tool. Linking each case to the merchant ID and agent lets the agent see open issues in the portal. Our case management and escalation guide covers queue and entitlement design.

What should a payments company never store in Salesforce?

Full card numbers, security codes and track data. Cardholder data belongs with PCI-compliant processors and tokenization services, not in a CRM.

PCI DSS sets the rules for cardholder data, and scope grows with every system that touches it. Keeping card data out of Salesforce usually reduces the CRM's PCI scope; your QSA confirms the final scope. This is general guidance, not legal or compliance advice; confirm your obligations with your QSA or compliance team.

Apply data minimization to everything else. Store only what the workflow needs.

• Card data: never stored. Reference processor tokens or merchant IDs instead.
• Owner identity documents for KYC: keep them in a secure document store or the underwriting system, and link rather than copy where possible.
• Bank account details: restrict with field-level security, or avoid storing them if the processor holds them.
• AML screening results: store the outcome and date, not the full screening report, unless policy requires it.
• Free-text fields: add validation or guidance so agents do not paste card numbers into notes.

Field-level security, permission sets and restriction rules limit who sees sensitive fields. Salesforce Shield adds encryption at rest, detailed event logs and longer field history for firms that need them. On legacy editions Shield is a separately licensed add-on. The 2026 Core, Advanced and Max editions bundle some data security, so confirm in writing which Shield capabilities your edition includes.

Where does AI fit for a payments sales team?

AI fits best in reading and summarizing Salesforce data for leaders, with a person approving anything that changes a record or reaches a customer.

Abstrakt Solutions helped Sync Payments connect Claude to the company's Salesforce data. One workflow, Daily Wins, reviews Salesforce activity and drafts recognition messages; a person reviews and posts each one. Another runs on a schedule, read-only, reviewing stale deals, slipping close dates, coverage and the quality of the forecast.

A separate pilot created Salesforce follow-up tasks from that analysis. Access was restricted, every write needed a person's approval first, and each action was logged. That pattern suits regulated businesses: start read-only, then add writes one at a time behind approval.

Set the rules before the first agent goes live. Our AI governance guide lists the decisions on data access, human review and monitoring.

What reports should payments leaders expect?

Reports should follow the merchant lifecycle: applications in flight, approval outcomes, boarding, active merchants, residuals and support load. Each needs a clear owner and definition.

• Application funnel by agent: submitted, pending documents, in underwriting, approved, declined.
• Time in stage, so you can see where applications stall.
• Approval and decline reasons, grouped so sales can fix recurring gaps.
• Active merchants by agent and processor, with attrition flagged.
• Residuals by agent and period, with unmatched lines visible.
• Open merchant cases by type, age and escalation status.

Agree the definitions first. "Approved" and "boarded" are different events, and mixing them makes every funnel report misleading.

What belongs in phase one for a payments company?

Phase one should give one place to see merchants, applications and agents, with intake and status tracking working end to end. Residual automation and AI can follow.

• Account hierarchy, merchant ID object and agent records, with external IDs from the processor.
• Application object with stages, required documents and internal approvals.
• E-signature for the main merchant agreement templates.
• A basic agent portal for application submission and status.
• Field-level security on sensitive fields, and a written rule that card data never enters Salesforce.
• Core funnel and status reports agreed with operations and sales leadership.

Processor integration can start in phase one if the API is well documented. Otherwise begin with file-based status updates and replace them later.