← Reference · Nestor G Pestelos Jr

Reference Document

Online Payments

A citable reference on how electronic money moves: 4-party card flows, CNP fraud mechanics, PCI DSS compliance, Ruby adapter abstractions, and US vs. Philippine interbank settlement rails.

1. The Core Split: Private Card Overlays vs. Public Rails

An electronic payment belongs to one of two fundamental architectures (detailed in US and Philippine Payment Rails):

1. Private Card Overlays (Visa, Mastercard, Amex): The network operates a messaging switch. The cardholder's bank issues credit or debit; the merchant's bank receives funds days later. Authorization is an instantaneous hold, not a settlement.
2. Public Interbank Settlement Rails (Fedwire, PhilPaSSplus, ACH, InstaPay): Banks maintain reserve accounts directly with the central bank (Federal Reserve or Bangko Sentral ng Pilipinas). Settlement transfers sovereign central bank balances between depository institutions.

2. The Four-Party Card Model

Open card networks operate across four distinct entities connected by the network switch:

The Payment Service Provider (PSP) Collapse

In legacy setups, merchants contracted separately with a Gateway (message encryption/routing), a Processor (network formatting), and an Acquirer (merchant account underwriting). Modern PSPs (e.g., Stripe, Adyen, Braintree) collapse all three into a single API contract and single payout schedule.

3. Card Transaction Lifecycle

A card transaction moves through three distinct chronological phases:

4. Card-Not-Present (CNP) & Security Regime

CNP Fraud & Liability

In Card-Present (CP) transactions with EMV chip-and-PIN, fraud liability rests with the party failing to support EMV (usually the issuer). In Card-Not-Present (CNP) e-commerce transactions, fraudulent chargebacks land by default on the merchant, who loses both the merchandise and the purchase price, plus a penalty fee.

3-D Secure (EMV 3DS) & PSD2 SCA

3-D Secure (3DS v2) is an XML/JSON messaging protocol that enables authentication directly between the consumer and their issuing bank prior to authorization.

• Frictionless Flow: Merchant passes device and behavioral telemetry to the issuer. If risk is low, authentication passes invisibly.
• Challenge Flow: High-risk transactions trigger step-up authentication (biometric, SMS OTP, or banking app approval).
• Liability Shift: Passing 3DS shifts the liability for fraudulent chargebacks from the merchant to the issuing bank.

PCI DSS & Scope Reduction

The Payment Card Industry Data Security Standard (PCI DSS) mandates security controls for entities storing, processing, or transmitting Cardholder Data (CHD).

• SAQ A (Hosted Fields / iFrames): Merchant servers never touch or receive the Primary Account Number (PAN). Card data is captured directly by PSP JavaScript into secure iframes. Self-Assessment Questionnaire A is minimal (~22 requirements).
• SAQ D (Direct API Intake): Card PAN touches merchant servers before forwarding. Requires full PCI DSS validation (~300+ technical controls and annual penetration testing).

5. Software Abstractions: ActiveMerchant & Rails

ActiveMerchant is an open-source Ruby payment library extracted by Shopify in June 2006. It standardizes disparate bank APIs behind a unified object-oriented interface:

• Standard Verbs: authorize(money, credit_card, options), capture(money, authorization, options), purchase(money, credit_card, options), void(authorization, options), refund(money, identification, options).
• Integer Cents Rule: All monetary amounts are passed as integers representing the currency subunit (e.g. 4000 for $40.00 USD) to prevent floating-point arithmetic errors.
• Response Envelope: Returns a standardized Response object indicating success?, authorization token, raw error messages, and AVS/CVC match codes.

6. Interbank Rails: United States vs. Philippines

A detailed architectural comparison of US and Philippine settlement mechanisms is explored in US and Philippine Payment Rails and InstaPay is Not ACH.

7. Comprehensive Glossary Index