What are embedded payments? A plain guide for software companies

Embedded payments means your customers take payments inside your software, at checkout, on an invoice or on a subscription, instead of in a separate processor's dashboard.

Every embedded setup answers two questions: who holds each merchant relationship, and who touches the money? Your risk, and your work under card network rules, money transmission law, tax reporting and PCI DSS, follow from them.

This guide covers the four common models, what each makes you responsible for under card network rules, and how to pick the lightest fit. Flux's referral and partner program is covered at the end.

What embedded payments means

Embedded payments is payment acceptance built into a software product or app, so the person paying never leaves it. It is usually treated as one part of "embedded finance", which also covers lending and banking features inside software.

"Integrated payments" is used loosely: some sources mean a back-office connection to an outside processor, others treat it as the same thing.

What it looks like

• A booking app takes a deposit when a client books.
• Invoicing or field-service software puts a Pay link on every invoice.
• Membership software charges renewals on schedule.

Why software companies embed payments

• One system. Customers get paid in the tool they already use and stop reconciling two systems.
• Better features. Payment status can drive the product: an invoice marks itself paid, a booking confirms once the deposit is in.
• Revenue. Payments can become a revenue line, and the model sets how. A payment facilitator (PF) sets its own pricing and keeps the margin over its costs; in a referral and partner model, compensation is set by the partner agreement.

What sits underneath

Three pieces are usually involved:

• The acquirer: the bank that signs businesses up to accept cards. Visa holds the acquirer responsible for the merchant and every entity operating between the acquirer and the merchant.
• The processor: the company that routes transactions and runs the payment technology.
• The merchant account: the agreement under which a business accepts cards and receives settlement, the money from its sales.

The four ways software companies embed payments

The four models differ on who signs each business up, whose name is on the card statement, who receives the money and who answers for disputes.

• Referral and partner. Each customer gets its own merchant account from a processor, and your software builds checkout, invoicing or subscriptions on the processor's API. Visa calls software a seller hires directly a "Merchant Servicer": it may not sign merchant agreements for an acquirer or receive settlement for the seller. Software that also solicits merchants on an acquirer's behalf may be treated as an acquirer's agent, such as an ISO (Independent Sales Organization). More on why your own merchant account matters.
• Payment facilitator. Your platform contracts with an acquirer and signs customers up as sponsored merchants. You control onboarding and the money, and take on the duties below.
• PayFac-as-a-service. An industry label, not a card network category. Most often, a provider is the registered PF and your users take payments under its registration; how losses and duties are split with you is set by contract.
• Marketplace. A separate Visa category (Visa Rule 5.3.4.1). The platform's brand leads, it handles payments and refunds for retailers, receives settlement for them and is financially liable for disputes.

Who is the merchant? The question that decides the rest

Visa broadly uses four principles to decide who the merchant is, set out in its guide Beyond the Acquirer: Additional Visa Acceptance Entities:

1. Whose name or brand the customer believes they are buying from.
2. Who owns or has the goods or services.
3. Who books the sale as revenue, rather than only a commission or fee.
4. Who handles customer service and returns, including refunds and disputes.

For most vertical software the answer is clear: a salon or contractor sells its own services, and your software is its tool, not the seller.

The answer shows on the receipt and the card statement. Under Visa Rules 5.9.2.2, the merchant name on the receipt for a payment involving a PF must show the PF's name and the sponsored merchant's (Visa's guide gives the format "PF*Seller DBA Name"), and a marketplace payment shows the marketplace and the retailer.

The line that catches people out: an entity that signs merchants for an acquirer, or receives settlement for sellers, "is considered a PF, even if they don't perform both functions," Visa's guide says. Receiving card settlement from an acquirer for your customers and passing it on is enough, unless you fit another Visa category such as a marketplace.

What the card networks require of a payment facilitator

These are the main PF duties in the Visa Rules (the Visa Core Rules and Visa Product and Service Rules, 24 October 2026) and the Mastercard Rules (2 June 2026).

Liability for every sub-merchant

Visa Rules 5.3.1.1 requires the PF agreement to make the PF liable for all acts, omissions, cardholder disputes and customer service issues caused by its sponsored merchants, and financially liable for each transaction it processes for them, including disputed transactions and credits.

Liability runs up the chain too: Visa treats a sponsored merchant as a merchant of the PF's acquirer (5.3.1.2), and Mastercard Rule 7.6.5 makes the acquirer responsible for all acts and omissions of both.

Registration, onboarding and monitoring

• Registration. Visa must confirm the PF's registration, including an attestation of due diligence review, before transactions flow, and each sponsored merchant gets its own identifier (5.3.1.3).
• Screening and reporting. Correct merchant category codes (MCCs), merchant and transaction reporting, and no merchants terminated at the direction of Visa or a government agency.
• Knowing each business. Mastercard lets the acquirer hand the PF the job of verifying each sponsored merchant is a bona fide business and monitoring it, but the acquirer remains fully responsible if the PF fails (Rule 7.6.5.1).
• Paying out. Under Mastercard Rule 7.8.2, the PF must pay each sponsored merchant for all transactions, and the duty is not met until the merchant receives the money. Settlement funds the PF can reach may be used only to pay sponsored merchants (Rule 7.6.5.1).
• PCI and monitoring. The PF must make sure sponsored merchants comply with PCI DSS (Visa 5.3.1.1), and Visa's Acquirer Monitoring Program (VAMP) may evaluate dispute and fraud levels for a single sponsored merchant (10.4.3.1).

Volume thresholds

Both networks cap how large a sponsored merchant can grow before it must sign directly with an acquirer.

A hypothetical example. Say your platform is a PF and an existing customer, a landscaping company, passes USD 1.2 million a year in Visa volume. Unless an exception applies, your acquirer has 2 years to sign it directly, though you may keep handling its payments. If its Mastercard volume is similar, it is far below USD 10 million, so the Mastercard threshold does not apply.

Fees, notice and termination

In the US region, Mastercard requires a plain-language fee disclosure and 30 days' notice of new or higher fees, and every sponsored merchant agreement ends automatically if the PF is de-registered or its acquirer stops being a Mastercard customer (Rule 7.8.1.1).

Touching the money: money transmission

Visa's guide warns that local laws may require a PF or marketplace to hold a money transmission license to receive and transmit settlement funds.

Federal rules define money transmission broadly: accepting funds from one person and transmitting them to another location or person by any means (31 CFR 1010.100(ff)(5)). Payment processors are excluded if they meet four conditions, listed in FinCEN ruling FIN-2014-R009 (August 27, 2014):

1. The service facilitates the purchase of goods or services, or the payment of bills for them.
2. It operates through clearance and settlement systems that admit only BSA-regulated financial institutions.
3. It is provided under a formal agreement.
4. The agreement is, at a minimum, with the seller or creditor that provided the goods or services and receives the funds.

The ruling answered a company acting as both an ISO and a payment processor. FinCEN found its ISO work did not make it a money transmitter, but could not confirm the second condition for its processing, as the company had not explained how it paid merchants.

State law is separate. More than 30 states have enacted the model Money Transmission Modernization Act in full or in part, according to the Conference of State Bank Supervisors. Many states also exempt a company collecting payment as the payee's agent, with conditions such as a written agreement, but the wording differs by state.

If your software will ever receive, hold or route customers' funds, have a payments attorney review the flow before you build.

PCI, tax forms and ACH rules still apply

PCI DSS

The PCI Security Standards Council defines a service provider as a business directly involved in processing, storing or transmitting cardholder data for another entity, including companies whose services could impact the security of that data. A platform that never stores a card number can still fall inside it.

Hosted fields, where the card number is typed into the provider's iframe, shrink PCI scope but do not remove it. The Council's January 2025 SAQ A update (effective 31 March 2025) removed requirements 6.4.3, 11.6.1 and 12.3.1 from SAQ A but added an eligibility criterion: merchants must confirm their site is not susceptible to script attacks that could affect their e-commerce systems. More on reducing PCI scope with hosted fields.

Form 1099-K

Under 26 U.S.C. 6050W, Form 1099-K is filed by the "payment settlement entity": for card payments, the organization with the contractual duty to pay the merchant. An intermediary that receives payments for several payees and distributes them takes on that role toward its payees. If an electronic payment facilitator (the statute's term) makes settlement payments on a payment settlement entity's behalf, the facilitator files in its place and is liable for penalties if it does not (Treas. Reg. 1.6050W-1(d)).

For third party settlement organizations, a 2025 law (Pub. L. 119-21) restored the threshold of over $20,000 and over 200 transactions, as if the $600 threshold never took effect. Card payments have no threshold: the IRS says card processors send a 1099-K no matter how many payments or how much. If your platform will pay customers out, ask a CPA which role you would hold.

ACH and the Nacha Rules

If your software originates ACH payments for customers through a bank, you may be a Third-Party Sender under the Nacha Rules, and each Third-Party Sender must do its own risk assessment. Nacha's fraud monitoring rules are now fully in effect: phase 1 began March 20, 2026 for all ODFIs and for non-consumer originators, third-party service providers and third-party senders with 2023 ACH origination volume of 6 million or more, and phase 2 covered the rest on June 19, 2026.

How to choose a model

Start from the lightest model and move up only when an answer below forces you to.

1. Do you want to own underwriting and your customers' disputes? A PF is liable for every sponsored merchant's. If not, look at referral and partner, or PayFac-as-a-service, where your share depends on the contract.
2. Who is the seller? If your customers sell their own goods or services under their own names, a marketplace is the wrong shape.
3. Will your software receive, hold or route customers' funds? Receiving settlement for sellers generally makes you a PF under Visa's definitions, unless you qualify as another category such as a marketplace, and moving funds raises money transmission questions. If you don't need to touch the money, don't.
4. Do you have staff for registration, monitoring, reporting and fee notices? A PF needs all of them, ongoing.
5. How big are your largest customers? Under a PF, any customer over USD 1 million a year in Visa volume needs a direct merchant agreement unless an exception applies.
6. Will you originate ACH? Then Nacha Rules duties apply, possibly as a Third-Party Sender.

If most answers are no, a referral and partner model is the lighter fit: your engineering goes into the product, the processor underwrites and pays each business directly, and disputes run against that business's own account.

A hypothetical example. Say you sell booking software to 300 fitness studios that each sell their own classes and handle their own refunds. Referred to a processor, each studio has its own merchant account and your software never holds their money. As a PF, you would control onboarding and the money, but take on registration, monitoring and 300 businesses' disputes.

This guide is general information, not legal or tax advice. Rules change, so confirm what applies to you with your acquirer, a payments attorney and a CPA.

How Flux works with software companies

Flux works with software companies through its referral and partner program. It is not a PayFac-as-a-service, and your platform does not sign businesses up under an account of its own. Each business you refer applies to Flux, a person reviews it, and it gets its own Flux account. Flux runs the payments, security and support.

Your software can build on the Flux Payments API (one integration for cards, ACH and stablecoins, with tokenization and webhooks), hosted fields and payment links. Stablecoin payments require at least $50,000 a month in stablecoin volume. Flux hosted fields capture card data in origin-isolated iframes on payments.fluxpayments.com, so it never touches your servers, for a much smaller PCI burden. Flux is PCI DSS SAQ-D Level 2 certified and SOC 2 Type I compliant, Type II in progress.

The GoHighLevel and Set Forth integrations work this way: a business connects its own Flux account to its workspace and takes payments inside software it already uses. For anything more specific, talk to the Flux team.

The Partner Portal is for agents, ISOs, referral partners and software companies to refer merchants and track each one from application to live processing. Partners are paid monthly under the partner agreement, can talk rates with the merchant, and Flux confirms the final rate upfront. To become a partner, email support@fluxpayments.com.