How Online Payments
Became a Business

Every online payment looks simple on the surface: a customer enters a card number, clicks Pay, and a confirmation appears. Under that button, however, lies a multi-step financial process involving merchants, processors, banks, networks, controls and operating models. This first lecture explains how that hidden machinery became a business of its own.

Imagine you have built a small online store.

You sell T-shirts for $50. A customer visits your website, chooses a shirt, enters a card number, and clicks Pay.

A few seconds later, the screen says:

Payment successful.

It looks simple.

But behind that button, many things have happened.

Your website had to securely collect the payment information. Someone had to contact the customer’s bank. The bank had to check whether the card was valid and whether enough money was available. Visa or Mastercard had to help route the transaction. Fraud checks may have been performed. Later, money has to move between financial institutions before eventually reaching your bank account.

And everyone involved needs to know exactly what happened to every dollar.

That hidden machinery is the payments industry.

1. A $50 Online Purchase Is Not Just a Transfer of $50

Suppose Emma buys a T-shirt from an online store called CoolShirts.

The price is $50.

At first glance, the transaction seems to be:

Emma → $50 → CoolShirts

In reality, it is closer to this:

Emma → CoolShirts → Payment Provider → Acquirer → Card Network → Emma’s Bank

and then the response travels back through the chain.

Emma's bank is called the issuing bank, or issuer, because it issued her card.

The financial institution on the merchant side is generally called the acquirer.

Visa or Mastercard operates the card network that connects participants and defines many of the rules under which card transactions operate.

When Emma clicks Pay, a request travels through this infrastructure asking, in simplified terms:

“

“Can we charge this card $50?”

Her bank checks the card, available funds or credit, security information, and other risk signals.

It may respond:

Approved.

Only then does CoolShirts know that the purchase can proceed.

Importantly, an approval does not mean that $50 instantly jumped from Emma's bank account into the merchant's bank account.

Authorization, capture, clearing, settlement, and payout are related but different stages of a payment.

We will study them later in the course.

For now, remember one important idea:

“

A payment is not one event. It is a process.

2. Why Doesn't Every Online Store Connect Directly to Banks?

Imagine that CoolShirts wants to accept:

• Visa;
• Mastercard;
• American Express;
• Apple Pay;
• Google Pay;
• PayPal;
• local European payment methods;
• US cards;
• European cards;
• several currencies.

The company would also need to think about card security, fraud, refunds, disputes, reporting, bank connections, transaction records, and many other issues.

Building all of this yourself would be extremely difficult.

This creates an obvious business opportunity:

“

What if another company built the payment infrastructure once and allowed thousands of businesses to use it?

This is where the Payment Service Provider, or PSP, enters our story.

3. PSP: Make Payments Easy

A PSP provides businesses with technology and services for accepting electronic payments. Instead of building separate connections to many parts of the payment ecosystem, a merchant can use one payment provider and one main integration.

A famous example is Stripe.

Suppose you create a new SaaS company called StudyCloud and charge students $20 per month.

Without a PSP, accepting cards globally could become a major engineering and financial-infrastructure project.

With Stripe, your developers can integrate payment APIs, create a checkout, accept cards and wallets, issue refunds, manage subscriptions, and use many additional payment services.

This is an enormous advantage.

Stripe became successful in large part because it made something extremely complicated feel relatively simple to developers and businesses.

Instead of thinking:

“

“How do we build a global payment infrastructure?”

a startup can think:

“

“How do we integrate Stripe?”

That difference is extremely valuable.

4. Why PSPs Are So Good

For many businesses, using a PSP is exactly the right decision.

Imagine you have just launched a startup.

You have 500 customers.

Payments are not your main product. Your main product might be hotel-management software, an e-commerce application, a booking platform, or an AI service.

You probably do not want to spend the next year building payment infrastructure.

You want to start accepting money.

A modern PSP gives you a shortcut.

This is why PSPs such as Stripe and Adyen are so powerful: they hide much of the complexity behind APIs, dashboards, integrations, and services. Adyen, for example, describes a PSP as a bridge connecting businesses, customers, and the financial institutions processing their transactions.

For a young company, this can be an excellent trade:

give up some control and economics in exchange for speed and simplicity.

But something interesting happens when the company grows.

5. What Happens When Payments Become Part of Your Product?

Imagine another company: HotelCloud.

HotelCloud provides software to 10,000 hotels.

Originally, HotelCloud only sells software.

Each hotel arranges its own payments.

Then HotelCloud realizes something:

“

“Our customers already use our software to manage reservations. Why do we send them somewhere else to manage payments?”

So HotelCloud integrates a PSP.

Now hotels can accept payments through HotelCloud.

This improves the product.

But eventually HotelCloud notices something even more important.

Suppose its 10,000 hotels process $5 billion per year.

Even a very small economic margin on $5 billion can become a significant business.

Payments are no longer just a feature.

Payments can become a product and a revenue stream.

This is where the business starts thinking beyond a simple PSP integration.

6. Enter the Payment Facilitator

A Payment Facilitator, usually shortened to PayFac, enables a platform to onboard merchants and facilitate payment processing for them.

Instead of every small business building its own payment relationship and infrastructure, the platform can manage a much larger part of that experience.

The businesses onboarded underneath the PayFac are commonly called sub-merchants.

A simplified structure looks like this:

Acquirer / Processor

↓

Payment Facilitator

↓

Hotel A — Hotel B — Hotel C — Hotel D — ...

A PayFac can onboard merchants on behalf of an acquirer, process their transactions, receive settlement funds under the applicable model, and pay funds out to sub-merchants.

That gives the platform much more control.

But control comes with responsibility.

The platform now has to care much more deeply about questions such as:

Who is this merchant?

Is this merchant legitimate?

What products does it sell?

How risky is it?

What fees should it pay?

When should it receive its money?

Should part of its balance be held in reserve?

What happens if its customers request chargebacks?

How do we reconcile processor records with our internal records and bank movements?

Suddenly, payments are no longer an API call.

They are an operating business.

7. Why Would Anyone Want This Complexity?

Because control over payments can be extremely valuable.

Consider HotelCloud again.

With a simple PSP arrangement, HotelCloud can provide payment functionality quickly.

With a more sophisticated platform or PayFac model, HotelCloud can potentially control much more of the payment experience:

Merchant onboarding

HotelCloud can make payment activation part of its own product experience.

Pricing

It can define how payment services are priced for its merchants.

Revenue

Payments can become an additional source of revenue instead of only an operating cost.

Payouts

The platform can have greater control over how and when merchants receive money.

Risk

It can apply risk rules appropriate to its particular industry.

Provider strategy

A sufficiently sophisticated platform does not necessarily have to design its entire business around one payment provider.

This is why platforms increasingly talk about embedded payments.

Stripe itself offers Stripe Connect for platforms and marketplaces, providing functionality such as merchant onboarding, embedded payments, payouts, and payment monetization.

The important lesson is therefore not that “PSPs are bad and PayFacs are good.”

They solve different problems.

A PSP is often excellent when your goal is:

“

“Help me accept payments.”

A PayFac-style model becomes interesting when the goal changes to:

“

“Payments are becoming part of my business.”

8. And Then There Is the Merchant of Record

Now imagine that our software company starts selling globally.

A customer in Germany buys a subscription.

Another customer is in California.

Another is in France.

Another is in Japan.

Accepting their cards is only one part of the problem.

Someone may also need to deal with taxes, refunds, chargebacks, invoicing requirements, payment compliance, fraud, and the legal responsibility associated with selling to customers in different markets.

This is where another model becomes important:

Merchant of Record — MoR.

A Merchant of Record is the entity that takes legal and financial responsibility for the sale to the end customer under the relevant arrangement.

A well-known example is Paddle, particularly for SaaS and digital-product companies.

Paddle acts as the Merchant of Record and handles areas including payments, tax, fraud, chargebacks, billing, and related compliance responsibilities for its model.

Imagine that StudyCloud wants to sell its $20 subscription in 50 countries.

With a traditional PSP relationship, StudyCloud generally remains responsible for many of the commercial and tax obligations surrounding those sales.

With an MoR provider such as Paddle, much more of that responsibility can be transferred to the MoR.

The difference can be summarized very simply.

A PSP says:

“

“We will help you get paid.”

A PayFac model says:

“

“We will help a platform operate payments for many merchants.”

An MoR says:

“

“For the covered sale, we will stand in the transaction as the merchant and take responsibility for much more of the commerce operation.”

This is deliberately simplified, but it gives you the correct mental model to start with.

9. So Is MoR “Better” Than PayFac, and PayFac “Better” Than PSP?

No.

Think of these as different operating models rather than software versions:

PSP → simplicity and speed

PayFac → control and payment economics

MoR → broader control and responsibility for the commercial transaction

A small SaaS startup may be making a terrible decision if it tries to build the infrastructure required for a sophisticated PayFac operation before it has customers.

A large software platform processing billions of dollars may be leaving significant strategic opportunities unexplored if it treats payments forever as nothing more than a connection to one PSP.

And a global digital seller may decide that becoming responsible for tax and payment operations in dozens of countries makes little sense when an MoR can take on much of that complexity.

The “best” model therefore depends on what the business is trying to accomplish.

10. A Useful Analogy: Selling Food

Imagine opening a restaurant.

A PSP is somewhat like a professional delivery company.

You make the food. You own the restaurant. The customer is your customer. The delivery company provides an important service that helps the order reach the customer.

A PayFac model is more like building a delivery platform used by thousands of restaurants.

Now you are not simply delivering your own food. You are onboarding restaurants, setting commercial rules, managing money flows, deciding how restaurants get paid, monitoring risk, and earning money from the infrastructure.

An MoR goes further in another direction. Imagine an organization that becomes the actual seller to the customer for the transaction and takes responsibility for collecting the payment and handling important obligations connected with that sale.

The analogy is imperfect, but it illustrates the progression in operational responsibility.

11. Where Does Amaryllis Fit?

This brings us to Amaryllis.

The easiest way to understand Amaryllis is to understand what it does not try to be.

Amaryllis does not simply say:

“

“Replace your payment processor with us.”

Instead, Amaryllis provides a technology and operational control layer for companies building sophisticated payment businesses.

Its platform is designed to support businesses starting with PSP infrastructure and evolving toward payment orchestration, PayFac operations, and MoR-ready operating models.

Think again about HotelCloud.

Perhaps HotelCloud already uses Stripe.

That does not necessarily mean:

“

“Throw Stripe away.”

Instead, the architecture can become conceptually:

HotelCloud

↓

Amaryllis

↓

Stripe / Adyen / other processors and payment providers

Amaryllis engineers would configure the payment operating layer around HotelCloud’s requirements. HotelCloud could then manage more of its payment business through that implemented solution, while underlying providers continue processing payments.

That distinction is fundamental.

12. Why Is That Important?

Suppose HotelCloud begins with one PSP.

Everything is simple.

Then it grows.

Now it wants two processors.

Different merchants need different pricing.

Hotels in different countries need different payment methods.

HotelCloud wants automated merchant onboarding.

It wants to split transaction economics between several parties.

It needs reserves.

It needs different payout schedules.

It needs risk controls.

It needs to understand chargebacks.

Finance needs reconciliation.

Management wants consolidated reporting across providers.

Eventually, the company's payment operation may look less like:

“Call Stripe API.”

and more like:

“Operate a financial system connecting thousands of merchants, multiple providers, millions of transactions, bank movements, fees, balances, payouts, risks, and accounting records.”

That second problem is the type of problem Amaryllis is designed to address.

Its current platform includes capabilities around merchant onboarding, pricing and fee logic, provider routing, payouts and settlements, ledger and reconciliation, reporting, risk, compliance, disputes, and multi-provider operations.

13. Amaryllis Is the Layer Above the Payment Rails

This gives us another useful mental model.

Think of Stripe, Adyen, acquiring banks, processors, and card networks as parts of the infrastructure that allows payments to happen.

Amaryllis sits at a different level.

It helps a company answer questions such as:

“

Which merchant does this transaction belong to?

“

Which provider should process it?

“

How much should the merchant be charged?

“

How should the fee be divided?

“

How much money belongs to the merchant?

“

How much belongs to the platform?

“

Should any money be reserved?

“

When should the merchant be paid?

“

Does the processor's settlement match what our system expected?

“

What happens when a chargeback arrives?

“

How do we see the same merchant and transaction lifecycle across multiple providers?

This is why describing Amaryllis simply as a “payment gateway” would miss much of its purpose.

It is better understood as an operating and control platform for a payments business.

Amaryllis describes this positioning as a control layer above the PSP, allowing companies to start PSP-first and add more control as their payment volume, economics, and operational complexity increase.

14. The Important Difference: Buy the Payment Operating System Instead of Building It

There is one final problem.

Imagine HotelCloud decides:

“

“Excellent. We will become a sophisticated payment company.”

Now it needs software.

It could spend years building systems for:

merchant onboarding,

transaction processing,

pricing,

billing,

risk,

compliance,

payouts,

reserves,

ledger,

reconciliation,

reporting,

disputes,

provider integrations,

and operational workflows.

Many companies historically built versions of these systems themselves.

Amaryllis was created around a different idea: companies should not have to repeatedly build the same payment infrastructure from scratch. Its founders describe the platform as a reusable technology stack for complex payment models, with modular SaaS capabilities covering the merchant lifecycle from onboarding through payout.

This is a major part of the Amaryllis value proposition:

“

Do not rebuild the payment operating system every time a software company decides to turn payments into a business.

Because the platform is modular and works with multiple processors, Amaryllis engineers can extend an implementation as a company’s payment model evolves, without necessarily rebuilding it around a new provider.

15. The Big Picture

If you remember only one thing from this introduction, remember this story.

A company starts by wanting to accept a payment.

So it uses a PSP.

As it grows, it realizes that payments can become part of its product and revenue model.

It begins to control merchant onboarding, pricing, risk, routing, balances, and payouts — moving toward a PayFac or embedded-payments model.

At an even broader level, some businesses need an MoR operating model in which responsibility extends beyond processing the payment to the commercial transaction itself.

And underneath all of these models lies an increasingly complicated operational system.

There are merchants.

There are customers.

There are transactions.

There are fees.

There are balances.

There are processors.

There are settlements.

There are payouts.

There are refunds.

There are chargebacks.

There are bank accounts.

And every cent must be accounted for.

This is the world in which Amaryllis operates.

It provides the technology layer that allows companies to manage that complexity and evolve their payments business without having to build the entire operating infrastructure themselves.

In the next chapter, we will go back to Emma's $50 T-shirt purchase and slow the process down.

We will follow that $50 step by step:

from the moment Emma clicks Pay, through authorization, capture, clearing and settlement, until the merchant finally receives the money.

Along the way, we will discover something important:

$50 paid by the customer does not mean $50 received by the merchant.

And understanding where the difference goes is the first step toward understanding the economics of the payments business.