How Do Online Payment Apps Like Wise and PayPal Actually Work?

Nhung Nguyen

Oct 13

14 min read

Introduction

Online payment applications have transformed the way people and businesses transfer money, pay for products, receive salaries, and conduct international transactions. Platforms such as Wise, PayPal, Stripe, Revolut, and other digital payment services allow users to move money across borders without visiting a traditional bank branch.

But have you ever wondered what happens behind the scenes when you click the “Send Money” or “Pay Now” button?

Does the money physically travel from one bank to another? How do these applications process payments in seconds? How do they make money from their services? And what technologies keep transactions secure?

To understand how online payment applications work, we need to examine the relationship between banks, payment networks, software systems, digital wallets, foreign exchange markets, and financial regulations.

1. What Is an Online Payment Application?

An online payment application is a digital platform that allows individuals and businesses to initiate, receive, manage, or process electronic payments.

These applications generally provide several core services:

Money transfers: Send money to another individual or business.
Online checkout: Pay for goods and services on websites.
Digital wallets: Hold a balance or manage linked payment methods.
International payments: Transfer money across countries and currencies.
Merchant payment processing: Help businesses accept customer payments.
Payment management: Track transactions, refunds, fees, and balances.

Although these services may appear similar to users, their underlying business models differ.

For example, PayPal offers digital wallet services and online checkout. Wise focuses on international transfers and multi-currency accounts. Stripe provides payment infrastructure that businesses integrate into their websites and applications.

The key distinction is that a payment application is not necessarily a bank. It may connect customers, banks, card networks, and payment processors while relying on regulated financial institutions to hold or transfer funds.

2. The Main Components of an Online Payment System

An online payment application operates through several interconnected components.

A. User interface

This is the mobile application or website that customers interact with.

When a user enters a recipient, payment amount, or card number, the interface collects the required information and sends a request to the platform's backend system.

Common technologies used to build these interfaces include:

React and Next.js for web applications.
Swift for native iOS applications.
Kotlin for native Android applications.
React Native or Flutter for cross-platform applications.

The user interface makes the service easy to use, but it does not independently move money.

B. Backend application

The backend is responsible for processing business logic and coordinating transactions.

It may handle:

User authentication.
Payment instructions.
Transaction validation.
Fee calculations.
Exchange-rate calculations.
Transaction status updates.
Refunds and payment disputes.
Fraud detection.

Backend systems can be developed using languages and frameworks such as Java, Python, Go, Node.js, and .NET.

C. Database and ledger

The database stores information about customers, accounts, payment instructions, transaction histories, and other operational records.

A particularly important component is the financial ledger.

The ledger records how much money belongs to each customer, how much the platform owes, and how funds move between accounts.

A robust ledger must maintain accurate balances and prevent the same payment from being recorded twice.

Many payment platforms use double-entry accounting principles, where every financial movement has corresponding debit and credit entries.

For example, if a platform transfers £100 from Customer A to Customer B within the same internal system, it might record:

Account	Debit	Credit
Customer A balance	£100	—
Customer B balance	—	£100
Total	£100	£100

This is a simplified illustration. Actual accounting entries depend on the platform's legal structure, custody arrangements, settlement process, and accounting policies.

D. Payment processor and payment networks

When a payment involves a debit card or credit card, the application may communicate with a payment processor, an acquiring bank, card networks, and the cardholder's issuing bank.

These organizations coordinate authorization, clearing, and settlement.

For bank transfers, the application may instead connect to a bank or a local payment system.

Examples include Faster Payments in the UK, SEPA payment schemes in Europe, and ACH in the United States.

E. Compliance and risk management

Payment platforms must identify customers where required, screen transactions, detect suspicious activity, and comply with applicable financial regulations.

Their systems may include:

Identity verification and Know Your Customer (KYC).
Anti-Money Laundering (AML) controls.
Sanctions screening.
Transaction monitoring.
Fraud detection.
Account security and access controls.

These systems operate alongside the payment infrastructure rather than as an afterthought.

3. What Happens When You Send Money Using Wise?

Imagine that Alice lives in the United Kingdom and wants to send £500 to Bob, who lives in France and wants to receive euros.

Here is a simplified example of how the transaction might work.

Step 1: Alice creates the transfer

Alice opens the Wise application, enters Bob's recipient details, and specifies that she wants to send £500.

The application displays the exchange rate, any applicable fees, the amount Bob should receive, and an estimated delivery time.

The exact rate, fees, and processing time depend on the transaction and the service's current terms.

Step 2: The application validates the transaction

Wise's systems validate the payment instruction and perform the necessary account, security, and compliance checks.

The platform may check whether Alice has sufficient funds, whether the recipient details are valid, and whether the transaction requires further review.

If the transaction fails a necessary check, it may be rejected, delayed, or referred for additional verification.

Step 3: Alice funds the transfer

Depending on the available funding method, Alice may pay through a bank transfer, debit card, or another supported method.

If she uses a bank transfer, her bank sends funds through the relevant payment infrastructure.

The payment application needs to establish whether the funds have arrived or whether the funding method provides sufficient confirmation to proceed.

Step 4: The currency conversion is calculated

Suppose the applicable exchange rate is:

[1\text{ GBP}=1.17\text{ EUR}]

Ignoring fees for the moment:

[£500\times1.17=€585]

If a hypothetical transfer fee of £3 is deducted from the amount Alice sends, the remaining £497 would convert to:

[£497\times1.17=€581.49]

The actual amount received depends on the exchange rate, fee structure, rounding rules, and transfer terms.

Step 5: The recipient receives euros

Wise may use its own payment accounts, local banking partners, or other payment arrangements to deliver the euros to Bob.

In some cases, the company can pay the recipient from funds it already holds in the destination country rather than sending an individual cross-border bank transfer for every transaction.

This is one reason international payments can be faster and less expensive than traditional correspondent-banking routes.

Step 6: The transaction is reconciled

The platform updates its internal records and reconciles the transfer against bank statements, payment confirmations, and other settlement information.

If a discrepancy arises, the finance and operations teams need to investigate it.

The transaction is not simply a message saying that money was sent. It must be supported by accurate financial records and appropriate controls.

4. How Does PayPal Process an Online Payment?

Now imagine that Alice wants to purchase a £100 product from an online retailer that accepts PayPal.

The process generally involves the following steps.

Step 1: Alice chooses PayPal at checkout

The retailer's website offers PayPal as a payment method.

Alice selects PayPal and authenticates with her account, often through a secure PayPal checkout experience.

Step 2: PayPal identifies the funding source

Depending on Alice's account and transaction, the funding source might be:

An existing PayPal balance.
A linked bank account.
A debit card.
A credit card.
Another supported funding arrangement.

The available methods depend on the country, account eligibility, and merchant configuration.

Step 3: PayPal evaluates the payment

PayPal processes the payment request and applies its authorization, risk, and compliance controls.

If a card is involved, the transaction may require authorization from the issuing bank through the relevant payment infrastructure.

If the payment uses a PayPal balance, the transaction may instead rely on the balance and internal ledger records.

Step 4: The merchant receives a payment confirmation

If the payment is approved, PayPal informs the merchant's system that the transaction has been completed or approved, according to the relevant payment flow.

The merchant can then decide whether to confirm the order or release the product.

A crucial distinction is that payment authorization is not always the same as final settlement. Some payments can subsequently be reversed, disputed, refunded, or subject to other adjustments.

Step 5: Settlement and reconciliation take place

Depending on the transaction, PayPal may owe money to the merchant, receive funds from a funding institution, or adjust balances within its own payment system.

The merchant may retain a balance with PayPal or withdraw funds to a bank account.

The platform reconciles the relevant payment records, balances, fees, and settlement movements.

5. The Difference Between Authorization, Clearing, and Settlement

These three terms are fundamental to understanding digital payments.

Authorization is the process of determining whether a payment can be approved. For a card payment, this often involves checking the card account and obtaining approval from the issuing bank.

Clearing involves exchanging transaction information and calculating the amounts that participating institutions owe each other.

Settlement is the process through which the resulting financial obligations are discharged, typically by transferring funds between financial institutions or through designated settlement arrangements.

The timing and exact sequence vary according to the payment method.

For example, an online card payment may receive an authorization almost immediately, while the associated clearing and settlement processes take place later.

A domestic bank transfer may follow a different process, particularly when the payment system supports near-real-time transfers.

Therefore, when a website says that a payment is successful, it does not necessarily mean that every institution involved has already completed final settlement.

6. How Do International Payment Applications Transfer Money Without Moving It Across Borders Every Time?

This is one of the most interesting aspects of international payment platforms.

Traditional international bank transfers can involve multiple financial institutions, including correspondent banks that maintain accounts with one another to facilitate cross-border payments.

This structure can introduce additional fees, processing steps, and delays.

Some international payment providers use a different model based on local collection and local payout.

Consider a simplified example.

Alice sends £500 from the UK to Bob in France.

<box border radius="xl" padding={4} gap={3}> <box background="surface-secondary" radius="lg" padding={3} align="center" gap={1}> <icon name="user-round" size="xl"/> Alice — United Kingdom <text color="secondary" size="sm">Pays £500 into a supported local collection account</text> </box> <box align="center" gap={1}> <icon name="arrow-down-up" size="2xl" color="secondary"/> <text color="secondary" size="sm">Payment instructions and internal ledger updates</text> </box> <box background="surface" border radius="lg" padding={3} align="center" gap={1}> <icon name="landmark" size="xl"/> Payment provider <text color="secondary" size="sm">Coordinates balances, currency conversion, risk checks and settlement</text> </box> <box align="center" gap={1}> <icon name="arrow-down" size="2xl" color="secondary"/> <text color="secondary" size="sm">Local payout in euros</text> </box> <box background="surface-secondary" radius="lg" padding={3} align="center" gap={1}> <icon name="user-round" size="xl"/> Bob — France <text color="secondary" size="sm">Receives euros in his bank account</text> </box> </box>

The provider might collect pounds in the UK and pay euros from an account or liquidity arrangement in France.

This does not mean that money never moves between countries. The provider still needs to manage its overall currency positions, funding requirements, liquidity, and obligations to financial institutions.

However, it may not need to initiate a separate international bank transfer for each individual customer transaction.

At scale, this approach can reduce costs and improve speed.

The precise arrangements vary by provider, corridor, currency, and transaction type.

7. How Do Payment Applications Make Money?

Payment applications generate revenue through several business models.

A. Transaction fees

Some services charge users a fee when they send money, especially for certain international transfers, funding methods, or business transactions.

For example, a hypothetical service might charge £3 for a transfer of £500.

Its revenue from that fee would be £3 before operating costs and other expenses.

B. Foreign exchange revenue

A provider may apply an exchange rate that includes a margin, or it may charge a separately disclosed currency-conversion fee.

Suppose the reference exchange rate is 1 GBP to 1.17 EUR, while a hypothetical provider offers 1 GBP to 1.16 EUR on a £1,000 conversion.

The difference in the converted amount is:

[€1{,}170-€1{,}160=€10]

That €10 is the difference between the two quoted conversion outcomes, not necessarily the provider's profit. The provider may incur hedging, liquidity, execution, and other costs.

C. Merchant processing fees

Business-focused payment platforms may charge merchants for processing card payments and other payment methods.

For example, assume an online retailer processes a £100 transaction and pays a hypothetical processing fee of 2% plus £0.20.

The fee would be:

[£100\times2%+£0.20=£2.20]

The merchant would receive £97.80 before any other deductions or adjustments.

Actual rates vary by country, payment method, transaction type, and commercial agreement.

D. Subscription and account fees

Some providers charge businesses or individuals for premium accounts, additional features, or specialist services.

These may include expense management, accounting integrations, additional user access, or advanced payment tools.

E. Other financial services

Depending on their regulatory permissions and business model, providers may generate revenue from services such as payment cards, business accounts, or eligible cash-management products.

Not every payment application offers these services, and not every revenue stream is available in every market.

8. The Technology Behind Online Payment Apps

Building a payment application requires considerably more than creating a mobile interface and connecting it to a database.

The architecture must support financial accuracy, security, reliability, and integration with external institutions.

A. APIs

An Application Programming Interface (API) allows software systems to communicate with each other.

For example, an online retailer may call a payment provider's API to create a payment, request an authorization, or retrieve the transaction status.

A simplified payment request might look like this:

POST /v1/payments
Authorization: Bearer <access_token>
Idempotency-Key: order-12345-payment-1
Content-Type: application/json

A simplified request body could contain:

{
  "amount": 10000,
  "currency": "GBP",
  "reference": "ORDER-12345"
}

In this example, the amount is represented in minor currency units, so 10000 means £100.00. The exact format depends on the API.

The idempotency key helps prevent an accidental retry from creating a second payment. The server must implement the corresponding idempotency logic correctly.

B. Backend services

A large payment platform may divide its backend into specialized services:

Customer and account management.
Payment orchestration.
Ledger and balance management.
Foreign exchange.
Fraud and compliance.
Notifications.
Reconciliation and reporting.

These services can operate together through APIs, queues, and internal messaging systems.

C. Databases and financial ledgers

Relational databases such as PostgreSQL or MySQL can support customer records, payment instructions, and financial transactions.

Payment systems also need carefully designed ledger structures that preserve transaction history and maintain balance integrity.

Critical controls include database transactions, unique transaction identifiers, concurrency handling, audit trails, and reconciliation.

A database row containing a payment status is not, by itself, sufficient proof that the underlying funds have settled.

D. Cloud infrastructure

Cloud platforms can provide computing capacity, database hosting, monitoring, backup, and disaster recovery.

Technologies such as Docker and Kubernetes may help teams deploy and scale application services.

However, scaling a payment system is not just a matter of adding more servers. The platform must also protect financial consistency, handle service failures, and recover safely from interrupted transactions.

E. Security and encryption

Payment applications commonly use multiple layers of security:

TLS encryption for data transmitted over networks.
Strong authentication and multi-factor authentication where appropriate.
Encryption and controlled access for sensitive stored data.
Secure credential and encryption-key management.
Fraud monitoring and suspicious-activity detection.
Access logging and security monitoring.
Tokenization and other methods to reduce exposure to sensitive card data.

For card payments, businesses that store, process, or transmit cardholder data must consider the applicable Payment Card Industry Data Security Standard (PCI DSS) requirements.

Security also depends on operational procedures, staff access controls, incident response, and regular testing.

9. How Do Payment Applications Prevent Fraud?

Digital payments face several types of fraud.

Stolen payment credentials: Criminals use compromised card details or account credentials to initiate transactions.

Account takeover: An attacker gains access to a legitimate customer's account.

Social engineering: A customer is persuaded to authorize a transfer to a fraudster.

Money laundering: Criminals attempt to disguise the origins or movement of illicit funds.

Merchant fraud: A merchant may misrepresent products, misuse payment information, or participate in fraudulent transactions.

Payment providers use a combination of automated technology and human investigation to manage these risks.

Machine-learning models may evaluate transaction amounts, account history, device signals, transaction velocity, and unusual behavioral patterns. Rules-based controls can also block transactions that meet defined risk criteria.

For example, a transaction may be referred for further authentication if it is inconsistent with the account's normal behavior.

However, no system can eliminate all fraud. Providers must balance fraud prevention, regulatory obligations, customer convenience, and the risk of incorrectly blocking legitimate payments.

10. What Happens When a Payment Fails?

A failed payment does not always mean that money has been permanently lost.

Several different scenarios are possible.

Scenario	What may happen
Insufficient funds	The payment may be declined before completion.
Incorrect recipient details	The transfer may be rejected, delayed, or require investigation.
Network timeout	The result may be uncertain until the system checks the payment status.
Duplicate payment request	Idempotency controls should prevent unintended duplication.
Card authorization declined	The payment may fail before capture or settlement.
Refund initiated	The platform records a refund and processes the associated financial adjustments.
Bank transfer returned	Funds may be returned after the receiving institution rejects the transfer.

One particularly important engineering challenge is handling an uncertain payment outcome.

Imagine that a payment request reaches the provider, but the application's connection times out before it receives the response.

The application must not assume that the payment failed and immediately create a new payment.

Instead, it should check the original transaction's status using the same idempotency key or a reliable transaction reference.

This is a critical principle in payment engineering: design for retries, interruptions, and uncertain outcomes without creating duplicate financial transactions.

11. The Accounting Behind a Payment Platform

Accounting is an essential part of payment infrastructure because the platform must maintain a clear record of funds received, funds owed, fees earned, refunds, and settlement movements.

Consider a simplified merchant payment.

A customer pays £100 through a payment provider. The provider charges the merchant a £2 processing fee and owes the merchant the remaining £98.

Illustrative entries in the provider's own books, assuming it receives and controls the funds and that the transaction is accounted for on a gross basis, might include:

When the customer payment is received and the merchant payable is recognized:

Account	Debit	Credit
Cash or settlement asset	£100	—
Merchant payable	—	£100

When the £2 fee is earned and deducted from the merchant's balance:

Account	Debit	Credit
Merchant payable	£2	—
Payment fee revenue	—	£2

When the merchant receives the remaining £98:

Account	Debit	Credit
Merchant payable	£98	—
Cash or settlement asset	—	£98

These entries are simplified illustrations. Actual accounting treatment depends on the provider's role, contractual terms, control of funds, applicable accounting standards, and whether it acts as principal or agent.

The customer and merchant may record different entries in their own accounting systems.

Payment companies must also consider chargebacks, expected credit losses where applicable, foreign exchange gains or losses, safeguarding obligations, and the accounting treatment of customer balances.

For finance teams, reconciliation is particularly important. Internal ledger balances should be matched against bank accounts, processor reports, payment network records, and settlement statements.

12. Is It Difficult to Build an Application Like Wise or PayPal?

A basic payment demonstration can be built relatively quickly, but creating a fully operational financial service is a much more complex undertaking.

A prototype might include:

User registration and login.
A dashboard showing account balances.
A mock transfer interface.
A transaction history.
A basic double-entry ledger.
Simulated payment statuses.
An administrative dashboard.

A production-ready payment business needs much more, including secure infrastructure, integrations with regulated financial institutions, operational controls, fraud prevention, reconciliation, customer support, and compliance with applicable regulations.

A sensible development roadmap would be:

Build a prototype: Demonstrate users, accounts, payment instructions, and transaction history using simulated funds.
Develop the ledger: Implement double-entry accounting, transaction integrity, audit trails, and balance checks.
Integrate a payment provider: Use an established provider's sandbox and API to learn how real payment flows operate.
Add security controls: Implement authentication, access control, encryption, monitoring, and safe transaction retries.
Build reconciliation: Match application records to external payment reports and settlement data.
Assess regulatory requirements: Determine which licenses, registrations, safeguarding arrangements, and compliance obligations apply to the proposed business and its jurisdictions.
Launch with controlled scope: Test thoroughly and work with qualified financial, legal, security, and operational specialists before handling real customer funds.

Developers should avoid holding customer funds or launching an unlicensed financial service merely because the software appears to work.

For a first project, integrating an established payment provider is usually more practical than attempting to build the entire financial infrastructure independently.

Conclusion

Online payment applications such as Wise and PayPal combine software engineering, banking infrastructure, financial ledgers, payment networks, foreign exchange, security, and regulatory compliance.

When a customer clicks a payment button, the application initiates a series of coordinated operations. These can include validating the transaction, checking available funds, requesting authorization, updating internal records, exchanging payment instructions with financial institutions, and reconciling the resulting settlement.

International transfer services can also use local collection and payout arrangements to avoid routing every customer transaction through a traditional chain of cross-border bank transfers.

The most important lesson is that a digital payment is not merely a transfer of money from one screen to another. It is a coordinated financial process supported by accurate records, trusted institutions, secure technology, and robust risk management.

Understanding these underlying mechanisms provides a useful foundation for anyone interested in fintech, payment processing, software development, digital banking, or financial technology entrepreneurship.

Resources : Internet