Kasha POS

The Starting Point

Kasha has zero clients today. We are building from scratch, which means every product decision must be laser-focused on what wins an SME merchant in the first meeting. There is no legacy to protect, no existing base to migrate — just a blank canvas and the urgency to ship something that merchants actually want to pay for.

This is NOT just a card terminal. Card acceptance is table stakes — every competitor already does it. Kasha POS is a full payment acceptance platform that covers the entire spectrum of how SME merchants get paid:

• Cards (tap & go via Adyen) — Visa, Mastercard, Amex, PostFinance. NFC contactless on the merchant's own phone (SoftPOS / Tap to Pay) or via a connected terminal.
• QR & mobile payments — CH TWINT (Switzerland's #1 mobile wallet, 5M+ users), BR Pix (Brazil's instant payment rail, 150M+ users).
• Open banking (direct IBAN settlement) — Bypass card networks entirely. Merchants receive funds directly into their bank account via SIC (CH) or Pix (BR), cutting fees to near zero.
• Payment anticipation (credit) — Killer differentiator. Merchants can advance their future card receivables and get cash today. In Brazil, this is a R$200B+ annual market. In Switzerland, it is virtually non-existent — a greenfield opportunity.

The Vision: "Square but Broader"

Think of Square, but designed from day one for multi-market, multi-payment-method reality. Square succeeded by making card acceptance dead simple for small businesses in the US. But in Switzerland and Brazil, cards are only part of the story. TWINT and Pix are dominant local rails that Square doesn't touch.

Kasha POS is a single platform where any small business can accept any local payment method, get settled fast, and access credit based on their sales history. The merchant doesn't need to juggle three different apps, two different terminals, and a separate lending relationship. One app. One dashboard. One settlement account. One credit line.

The credit piece is what transforms Kasha from a payment tool into a financial platform. A merchant who depends on Kasha for both payments and working capital is a merchant who never churns.

CH Switzerland

BR Brazil

Market Comparison

Use Case Matrix

Mapping each core use case to the personas it serves and the Kasha modules required.

Full Payment Methods Table

Rollout Phases

Infrastructure Stack

CH BR Adyen Integration

Adyen serves as the primary PSP for Switzerland and handles international card payments in Brazil. The integration covers the full merchant lifecycle from sub-merchant onboarding through to settlement and capital lending.

API Surface

• Terminal API -- In-person card-present payments via physical terminals or SoftPOS devices
• Checkout API -- Online and QR-code-based payments, including TWINT for Swiss customers
• Platforms API -- Sub-merchant management using the marketplace model; each Kasha merchant is a sub-merchant under Kasha's Adyen platform account
• TWINT via Local Payment Methods -- Adyen's native TWINT integration for the Swiss market, presented as a payment option alongside cards
• Apple Tap to Pay via SoftPOS SDK -- Enables merchants to accept contactless payments directly on iPhone, no additional hardware required
• Adyen Capital -- Merchant lending for CH only, available in Phase 4. Requires a minimum of 4 months of transaction history per client before an offer can be extended (Adyen's policy)
• Webhook Notifications -- Real-time payment status updates (AUTHORISATION, CAPTURE, REFUND, CHARGEBACK) delivered to lr-pos-service via lr-api-gateway

AdyenService Interface

// src/providers/adyen/adyen.interface.ts

interface IAdyenService {
  /**
   * Create a new payment request via Adyen Checkout or Terminal API.
   * Determines the correct API based on the payment channel (in-person vs online).
   * @param dto - Payment creation parameters (amount, currency, method, merchantRef)
   * @returns Payment result with PSP reference and status
   * @throws AdyenApiError if the request fails
   */
  createPayment(dto: ICreatePaymentDto): Promise<IPaymentResult>;

  /**
   * Capture a previously authorised payment.
   * @param pspReference - Adyen's unique payment reference
   * @param amount - Amount to capture (supports partial capture)
   * @returns Capture result with updated status
   */
  capturePayment(pspReference: string, amount: IAmount): Promise<ICaptureResult>;

  /**
   * Refund a captured payment (full or partial).
   * @param pspReference - Adyen's unique payment reference
   * @param amount - Amount to refund
   * @returns Refund result with PSP refund reference
   */
  refundPayment(pspReference: string, amount: IAmount): Promise<IRefundResult>;

  /**
   * Create a sub-merchant account under Kasha's Adyen platform.
   * Used during merchant onboarding to set up payment processing.
   * @param dto - Merchant details (legal name, address, bank account)
   * @returns Created sub-merchant with Adyen account holder ID
   */
  createSubMerchant(dto: ICreateSubMerchantDto): Promise<ISubMerchant>;

  /**
   * Register a device for Apple Tap to Pay (SoftPOS).
   * Links the merchant's iPhone to their Adyen terminal profile.
   * @param dto - Device details (model, OS version, merchant terminal ID)
   * @returns Registered device with activation code
   */
  registerSoftPosDevice(dto: IRegisterDeviceDto): Promise<IDevice>;

  /**
   * Check and initiate a capital offer for a Swiss merchant.
   * Only available for merchants with 4+ months of transaction history.
   * @param merchantId - Internal Kasha merchant ID
   * @returns Capital offer details, or null if merchant is not eligible
   */
  initiateCapitalOffer(merchantId: string): Promise<ICapitalOffer | null>;
}

BR Transfero Integration

Transfero is the primary PSP for Brazil, providing native Pix integration, BRZ stablecoin settlement, and a crypto on-ramp. This enables Brazilian merchants to accept the most popular local payment methods while optionally settling in stablecoins for currency stability.

API Surface

• Pix API -- Instant payment via QR code generation (dynamic and static), Pix Copy & Paste, and Pix Tap to Pay (NFC-based Pix on Android devices)
• BRZ Stablecoin Settlement -- Merchants can opt to receive settlement in BRZ (real-pegged stablecoin) instead of BRL, reducing exposure to banking delays and enabling instant cross-border value transfer
• Crypto On-ramp -- Accept BTC and ETH payments from customers; funds are automatically converted to BRZ or BRL at the time of transaction, shielding the merchant from volatility
• Merchant Management API -- Create and manage merchant accounts, configure settlement preferences (BRL vs BRZ), set up Pix keys
• Webhook Notifications -- Real-time Pix confirmation (typically under 3 seconds), settlement status, and crypto conversion confirmations

TransferoService Interface

// src/providers/transfero/transfero.interface.ts

interface ITransferoService {
  /**
   * Create a Pix payment with dynamic QR code.
   * Generates a unique QR code for the specific transaction amount.
   * @param dto - Pix payment details (amount, merchantPixKey, description)
   * @returns Pix result with QR code data, copy-paste code, and transaction ID
   * @throws TransferoApiError if QR generation fails
   */
  createPixPayment(dto: ICreatePixDto): Promise<IPixResult>;

  /**
   * Create a Pix Tap to Pay (NFC) payment session.
   * Enables the merchant's Android device to receive Pix via NFC tap.
   * @param dto - Tap payment details (amount, device ID, merchant ID)
   * @returns Tap session with NFC payload and timeout
   */
  createPixTapPayment(dto: IPixTapDto): Promise<IPixTapResult>;

  /**
   * Initiate BRZ stablecoin settlement for a batch of transactions.
   * Converts accumulated BRL to BRZ and transfers to merchant's wallet.
   * @param dto - Settlement details (merchant ID, amount, destination wallet)
   * @returns Settlement result with BRZ amount and transfer hash
   */
  createBrzSettlement(dto: IBrzSettlementDto): Promise<ISettlementResult>;

  /**
   * Query the real-time status of a Pix transaction.
   * @param transactionId - Transfero transaction reference
   * @returns Current Pix status (PENDING, CONFIRMED, EXPIRED, RETURNED)
   */
  getPixStatus(transactionId: string): Promise<IPixStatus>;

  /**
   * Register a new merchant with Transfero.
   * Sets up Pix keys, settlement preferences, and compliance data.
   * @param dto - Merchant registration details (CPF/CNPJ, bank account, Pix key)
   * @returns Created merchant with Transfero merchant ID
   */
  createMerchant(dto: ICreateMerchantDto): Promise<IMerchant>;

  /**
   * Generate a static QR code for a merchant (reusable, no fixed amount).
   * Customer enters the amount when scanning. Ideal for tipping or variable pricing.
   * @param merchantId - Internal Kasha merchant ID
   * @returns Static QR code with image URL and Pix copy-paste payload
   */
  generateStaticQrCode(merchantId: string): Promise<IStaticQrCode>;
}

CH Banking Provider -- Direct IBAN Settlement

For Swiss merchants, Kasha offers direct IBAN-based settlement bypassing traditional payment processor settlement cycles. This uses the Swiss Interbank Clearing (SIC) system and open banking APIs for a lower-cost, faster settlement path.

Capabilities

• SIC (Swiss Interbank Clearing) -- CHF transfers through the Swiss National Bank's real-time gross settlement system. Enables same-day settlement for qualifying merchants with verified IBANs
• Open Banking APIs -- Account verification, balance checks, and automated reconciliation via PSD2-compliant open banking connections to Swiss banks
• Same-day Settlement -- Qualifying merchants (verified identity, 30+ days active, no chargebacks) receive funds on the same business day. Standard merchants receive T+1 settlement

Settlement Tiers

Provider Routing Logic

The POS service automatically routes each payment to the correct provider based on the merchant's country, the selected payment method, and the customer's preference. The routing decision is transparent to the merchant UI.

Payment Request Received
        |
        v
  +-----------+
  | Country?  |
  +-----+-----+
        |
   +----+----+
   |         |
   v         v
  CH        BR
   |         |
   v         v
 Method?   Method?
   |         |
   +--+      +--+--+--+
   |  |      |  |  |  |
   v  v      v  v  v  v
 Card TWINT Pix Card BRZ Crypto
   |   |     |   |   |    |
   v   v     v   v   v    v
 Adyen Adyen  T   A   T    T
              r   d   r    r
              a   y   a    a
              n   e   n    n
              s   n   s    s
              f       f    f
              e       e    e
              r       r    r
              o       o    o

  A = Adyen    T = Transfero

Flow 1: Simple Walk-in CH BR

Scenario: A customer buys a coffee and pastry at a bakery. The merchant enters the total amount. The customer pays by tapping their card (CH) or scanning a Pix QR code (BR).

Customer          Merchant POS          lr-pos-service         PSP (Adyen/Transfero)
   |                   |                      |                         |
   | Orders coffee     |                      |                         |
   |------------------>|                      |                         |
   |                   |                      |                         |
   |                   | Enter amount (CHF 7) |                         |
   |                   |--------------------->| Create session          |
   |                   |                      | (type: SIMPLE)          |
   |                   |                      |                         |
   |                   | Show payment options  |                         |
   |                   |<---------------------|                         |
   |                   |                      |                         |
   | Taps card / Scans QR                     |                         |
   |------------------>|                      |                         |
   |                   | Payment request      |                         |
   |                   |--------------------->| Route to PSP            |
   |                   |                      |------------------------>|
   |                   |                      |                         |
   |                   |                      |    Payment confirmed    |
   |                   |                      |<------------------------|
   |                   |                      |                         |
   |                   | Success + Receipt    |                         |
   |                   |<---------------------|                         |
   |                   |                      |--> RabbitMQ:            |
   | Receipt (QR/email)|                      |    pos.payment.completed|
   |<------------------|                      |    --> invoicing        |
   |                   |                      |                         |

   Total time: <10 seconds (card) / <5 seconds (Pix)

Flow 2: Booking + Deposit + Final Payment CH BR

Scenario: A customer books a phone repair at a repair shop. A 30% deposit is collected at booking time. After repair is complete, the remaining 70% is collected. The entire flow spans two POS sessions linked to a single booking.

Phase 1: Booking + Deposit
==========================
Client books repair via lr-booking-service
        |
        v
lr-booking-service creates booking (status: CONFIRMED, deposit_required: true)
        |
        | RabbitMQ: booking.deposit.required
        v
lr-pos-service creates POS session (type: DEPOSIT, booking_id: BK-001)
        |
        v
Merchant POS shows: "Deposit required: CHF 60.00 (30% of CHF 200.00)"
        |
        v
Customer pays deposit (card / TWINT / Pix)
        |
        v
lr-pos-service records transaction, publishes pos.payment.completed
        |
        +--> lr-invoicing-service creates invoice (status: PARTIALLY_PAID)
        |    Line item: "Phone repair deposit - 30%"  CHF 60.00
        |
        +--> lr-booking-service updates booking (deposit_status: PAID)


Phase 2: Repair + Final Payment
================================
Merchant completes repair, marks booking as COMPLETED
        |
        | RabbitMQ: booking.completed
        v
lr-pos-service creates POS session (type: FINAL_PAYMENT, booking_id: BK-001)
        |
        v
Merchant POS shows: "Final payment: CHF 140.00 (remaining on BK-001)"
        |
        v
Customer pays remaining amount
        |
        v
lr-pos-service records transaction, publishes pos.payment.completed
        |
        +--> lr-invoicing-service updates invoice (status: PAID)
        |    Line item added: "Phone repair - final payment"  CHF 140.00
        |
        +--> lr-booking-service updates booking (status: CLOSED)
        |
        +--> Receipt sent to client (email/SMS/WhatsApp)

Flow 3: Catalogue Sale with Stock CH BR

Scenario: A customer at a boutique selects two items. The merchant scans or selects the items from the catalogue. Stock is checked, payment is processed, stock is decremented, and an invoice with line items is generated.

Customer          Merchant POS        lr-pos-service      lr-catalogue-service
   |                   |                    |                      |
   | Selects items     |                    |                      |
   |------------------>|                    |                      |
   |                   |                    |                      |
   |                   | Scan/select items  |                      |
   |                   |------------------->| Create session       |
   |                   |                    | (type: CATALOGUE_SALE)|
   |                   |                    |                      |
   |                   |                    | Check stock          |
   |                   |                    |--------------------->|
   |                   |                    |                      |
   |                   |                    | Stock confirmed      |
   |                   |                    |<---------------------|
   |                   |                    |                      |
   |                   | Cart:              |                      |
   |                   | Silk scarf  x1 CHF 45                    |
   |                   | Earrings    x1 CHF 28                    |
   |                   | ─────────────────  |                      |
   |                   | Total:     CHF 73  |                      |
   |                   |<-------------------|                      |
   |                   |                    |                      |
   | Pays (card/Pix)   |                    |                      |
   |------------------>|                    |                      |
   |                   |------------------->| Process payment      |
   |                   |                    |--> PSP               |
   |                   |                    |                      |
   |                   |                    | Payment confirmed    |
   |                   |                    |                      |
   |                   |                    | RabbitMQ: pos.sale.completed
   |                   |                    |--------------------->|
   |                   |                    |                      | Decrement stock:
   |                   |                    |                      | Silk scarf: 12 -> 11
   |                   |                    |                      | Earrings: 5 -> 4
   |                   |                    |                      |
   |                   |                    |                      | Stock check:
   |                   |                    |                      | Earrings below
   |                   |                    |                      | threshold (5)!
   |                   |                    |                      |
   |                   |                    | catalogue.stock.low  |
   |                   |                    |<---------------------|
   |                   |                    |                      |
   |                   | Receipt + restock  |                      |
   |                   | alert              |                      |
   |                   |<-------------------|                      |
   |                   |                    |                      |
   | Receipt           |                    | --> lr-invoicing:    |
   |<------------------|                    |   Invoice with 2     |
   |                   |                    |   line items (PAID)  |

Session State Machine

The session lifecycle is enforced by a finite state machine. Invalid transitions are rejected, ensuring data consistency. The following diagram shows all valid transitions:

                      ┌─────────┐
                      │ CREATED │
                      └────┬────┘
                           │
                 ┌─────────┼─────────┐
                 │         │         │
                 v         v         v
          ┌────────────┐  ┌──────────────┐
          │ITEMS_ADDED │  │  AMOUNT_SET  │◄──── (simple/booking sessions
          └─────┬──────┘  └──────┬───────┘      skip ITEMS_ADDED)
                │                │
                └──────┬─────────┘
                       │
                       v
              ┌─────────────────┐
              │ PAYMENT_PENDING │
              └────────┬────────┘
                       │
                       v
            ┌────────────────────┐
            │PAYMENT_PROCESSING  │
            └─────────┬──────────┘
                      │
            ┌─────────┼──────────┐
            │         │          │
            v         v          v
     ┌──────────┐ ┌──────────┐ ┌──────────────┐
     │COMPLETED │ │  FAILED  │ │   EXPIRED    │
     └────┬─────┘ └──────────┘ └──────────────┘
          │
          v
  ┌────────────────┐
  │RECEIPT_GENERATED│
  └───────┬────────┘
          │
          v
     ┌──────────┐
     │ SETTLED  │
     └──────────┘

Error states: PAYMENT_FAILED and PAYMENT_EXPIRED are terminal states from which a new session must be created. There is no "retry" on a failed session -- the merchant creates a fresh session. This keeps the audit trail clean: every session ID maps to exactly one payment attempt.

POS ↔ Invoicing (lr-invoicing-service)

Every POS payment can generate an invoice or receipt. The invoicing service is the system of record for all financial documents, while the POS service owns the payment lifecycle. Their integration ensures that every payment has a corresponding financial document.

Integration Points

• Receipt creation: Every completed POS session triggers invoice/receipt generation in the invoicing service
• Deposit tracking: Booking deposits create partial invoices with status PARTIALLY_PAID. The invoice tracks the total owed vs. the amount collected
• Final payment closure: When a final payment session completes, the existing invoice is updated to PAID and all line items are reconciled
• Line item mapping: For catalogue sales, each POS line item (product, quantity, price, tax) maps directly to an invoice line item, ensuring tax compliance

RabbitMQ Events

POS ↔ Banking (lr-banking-service)

The banking service manages the actual movement of funds -- from PSP settlement accounts to merchant bank accounts. The POS service tells the banking service when and how much to transfer; the banking service handles the how.

Integration Points

• Settlement transfers: When a settlement batch is ready, the POS service publishes the net amount and the merchant's bank details. The banking service initiates the transfer via SIC (CH) or Pix/TED (BR)
• Anticipation disbursements: When a merchant requests receivables anticipation (BR), the POS service calculates the eligible amount and fee, then instructs the banking service to disburse from Kasha's treasury
• Reconciliation: The banking service reports on confirmed bank movements. The POS service matches these against expected settlements to detect discrepancies

RabbitMQ Events

POS ↔ Bookings (lr-booking-service)

The booking service manages appointments and service scheduling. When a booking requires a financial transaction (deposit or final payment), it delegates to the POS service. This separation ensures that scheduling logic stays in the booking service while payment logic stays in the POS service.

Integration Points

• Deposit collection: When a booking is created with deposit_required=true, the booking service emits an event. The POS service creates a deposit session pre-filled with the calculated deposit amount and linked to the booking ID
• Final payment: When the merchant marks a booking as complete, the POS service creates a final payment session for the remaining balance. The amount is automatically calculated by subtracting any deposits already collected
• Booking reference: Every POS session that originates from a booking carries a booking_id field, enabling full traceability from appointment to payment to invoice
• Configurable deposits: Deposit percentages and rules are configurable per service type in the booking service (e.g., 30% for repairs, 50% for custom orders, 0% for standard appointments)

RabbitMQ Events

POS ↔ Catalogue (lr-catalogue-service)

Merchants who sell physical goods use the catalogue service to manage their product inventory. The POS service integrates with the catalogue for item lookup during sales and stock management after payment. The same catalogue powers both in-store POS sales and online e-commerce via lr-ecommerce-service.

Integration Points

• Product lookup: The POS UI can browse the merchant's catalogue, search by name, or scan barcodes/SKUs. Product data (name, price, image, stock count) is fetched from the catalogue service
• Stock validation: Before finalizing a sale, the POS service checks that sufficient stock is available for each line item. If an item is out of stock, the sale cannot proceed for that item
• Stock decrement: On successful payment, the POS service publishes a pos.sale.completed event containing the list of items sold and their quantities. The catalogue service decrements stock accordingly
• Restock alerts: When stock falls below a merchant-configured threshold, the catalogue service emits a catalogue.stock.low event. This triggers a notification to the merchant via the POS UI and/or push notification

RabbitMQ Events

POS ↔ CRM (lr-crm-service)

The CRM integration is optional but valuable. When enabled, the POS service can link payments to customer profiles, enabling merchants to track purchase history, spending patterns, and loyalty. This transforms the POS from a simple payment tool into a customer relationship channel.

Integration Points

• Customer linking: At payment time, the merchant can optionally link the transaction to a customer profile (by phone number, email, or loyalty card). This is never required -- walk-in anonymous payments are always supported
• Purchase history: Linked payments appear in the customer's CRM profile, giving the merchant visibility into spending patterns, visit frequency, and product preferences
• Loyalty & visit tracking: The CRM service can maintain loyalty points or visit counts based on POS transactions. Merchants can configure rewards (e.g., "10th coffee free") that are applied automatically

RabbitMQ Events

POS ↔ Luma AI (lr-luma-service)

Luma is Kasha's AI agent. It can query POS data to answer merchant questions in natural language, trigger POS actions on behalf of the merchant, and proactively surface business insights. The POS service exposes a set of query and action endpoints that Luma can invoke via RabbitMQ RPC calls.

Luma Can Query POS Data

• "How much did we make today?" -- Luma queries the POS analytics endpoint for today's transaction totals, broken down by payment method
• "What's our best-selling item this week?" -- Luma queries POS + catalogue data to rank items by sales volume and revenue
• "Show me all refunds from last month" -- Luma queries the transaction history with filters for refund transactions
• "Compare this month's sales to last month" -- Luma queries POS analytics for period-over-period comparison

Luma Can Trigger POS Actions

• "Refund the last transaction" -- Luma identifies the most recent completed transaction and initiates a refund via the POS service
• "Send a receipt to the customer" -- Luma triggers receipt re-send for a specified transaction
• "What's my anticipation balance?" -- Luma queries the merchant's available anticipation amount and current terms (BR only)

POS Feeds Luma's Business Insights

• Daily sales summaries are published as events that Luma indexes for trend analysis
• Anomaly detection: unusual transaction volumes, high refund rates, or settlement delays are flagged to Luma for proactive merchant notification
• Peak hour analysis: POS session timestamps help Luma identify busiest periods and suggest staffing or pricing optimizations

RabbitMQ Interactions

Complete Event Catalogue

For reference, here is the complete list of RabbitMQ events published and consumed by lr-pos-service:

Events Published by POS

Events Consumed by POS

How It Works

When a merchant accepts a card payment in Brazil, the acquirer (Adyen) holds the funds for up to 30 days before settling. This is standard industry practice, but it creates severe cash flow problems for SMEs who need working capital now to pay suppliers, staff, and rent.

• Standard flow: Merchant accepts card → Adyen holds funds → settlement at T+30 → merchant waits a full month
• Kasha anticipation flow: Merchant accepts card → requests anticipation → Kasha advances funds at 1-2% discount → merchant receives funds next business day
• Kasha treasury funds the advance from its own capital reserves
• At T+30, Adyen settles the full original amount to Kasha, closing the loop
• The spread (1-2% fee) is pure margin for Kasha, with risk managed by the scoring algorithm

This is massive for Brazilian SMEs. The antecipacao de recebiveis market exceeds R$200 billion annually, and traditional banks charge 2-5% for equivalent services. Kasha's 1-2% rate is highly competitive.

Risk Scoring Algorithm

Every anticipation request is evaluated by an automated risk scoring engine that assesses merchant reliability and determines approval, maximum amount, and fee rate.

// src/modules/anticipation/anticipation.interface.ts

interface IRiskScoringInput {
  merchantId: string;
  monthlyVolume: number;        // average monthly card volume
  chargebackRate: number;      // % of transactions charged back
  merchantTenureMonths: number; // how long on the platform
  requestedAmount: number;     // how much they want to anticipate
  totalReceivables: number;    // total outstanding receivables
}

interface IRiskScoringResult {
  grade: 'LOW' | 'MEDIUM' | 'HIGH' | 'REJECTED';
  maxApprovedAmount: number;
  suggestedFeePercent: number;  // 1.0% for LOW, 1.5% for MEDIUM, 2.0% for HIGH
  reasons: string[];
}

// ──────────────────────────────────────────────────────
// Scoring factors:
// ──────────────────────────────────────────────────────
// - Chargeback rate > 1%           → penalty (+1 risk level)
// - Monthly volume consistency      → 3-month std dev analysis
//   (high variance = unpredictable revenue = higher risk)
// - Merchant tenure < 3 months      → higher risk (insufficient history)
// - Request > 80% of receivables    → higher risk (over-leveraged)
// - HARD LIMIT: Never approve > 90% of total receivables
// ──────────────────────────────────────────────────────

function calculateRiskScore(input: IRiskScoringInput): IRiskScoringResult {
  let riskPoints = 0;
  const reasons: string[] = [];

  // Factor 1: Chargeback rate
  if (input.chargebackRate > 0.02) {
    return { grade: 'REJECTED', maxApprovedAmount: 0, suggestedFeePercent: 0,
             reasons: ['Chargeback rate exceeds 2% threshold'] };
  }
  if (input.chargebackRate > 0.01) { riskPoints += 2; reasons.push('Elevated chargeback rate'); }

  // Factor 2: Merchant tenure
  if (input.merchantTenureMonths < 1) {
    return { grade: 'REJECTED', maxApprovedAmount: 0, suggestedFeePercent: 0,
             reasons: ['Minimum 1 month tenure required'] };
  }
  if (input.merchantTenureMonths < 3) { riskPoints += 1; reasons.push('Limited platform history'); }

  // Factor 3: Receivables ratio
  const ratio = input.requestedAmount / input.totalReceivables;
  if (ratio > 0.9) { riskPoints += 3; reasons.push('Exceeds 90% cap - will be reduced'); }
  else if (ratio > 0.8) { riskPoints += 1; reasons.push('High receivables utilization'); }

  // Determine grade and fee
  const grade = riskPoints <= 1 ? 'LOW' : riskPoints <= 3 ? 'MEDIUM' : 'HIGH';
  const feeMap = { LOW: 1.0, MEDIUM: 1.5, HIGH: 2.0 };
  const maxAmount = Math.min(input.requestedAmount, input.totalReceivables * 0.9);

  return { grade, maxApprovedAmount: maxAmount, suggestedFeePercent: feeMap[grade], reasons };
}

Anticipation Request Flow

The end-to-end process from merchant request to fund disbursement:

Adyen Capital — Merchant Lending

Unlike Brazil's in-house receivables advance model, Switzerland leverages Adyen Capital, a merchant lending product managed entirely by Adyen. This is not a receivables advance — it is a proper loan product.

• Eligibility: Requires a minimum of 4 months of transaction history on the Kasha platform (Adyen's internal underwriting rules)
• Risk ownership: Adyen manages all credit risk, underwriting, and collections — Kasha has zero balance sheet exposure
• Revenue model: Kasha earns a commission on each loan originated through the platform
• Repayment: Automatic deduction as a percentage of daily card sales — no fixed monthly installments
• Availability: Planned for Phase 4 of the Kasha POS rollout, after sufficient merchant transaction history is established

Anticipation Model Comparison

Platform Architecture

Kasha operates as an Adyen Platforms account holder — a marketplace model where Kasha is the platform and each merchant is a sub-merchant (referred to as an "account holder" in Adyen terminology).

• Split payments: Every transaction is automatically split between Kasha's commission account and the merchant's payout balance. No manual reconciliation needed.
• Automated KYB: Adyen's verification API handles identity checks, document validation, and screening against sanctions lists. Results are relayed back to Kasha via webhooks.
• Payout scheduling: Each sub-merchant has configurable payout schedules (daily, weekly, or on-demand) to their registered bank account.
• Multi-country: A single Adyen Platforms integration supports both CH and BR sub-merchants, with country-specific compliance handled by Adyen's regional entities.

While SoftPOS is the core strategy, some merchants may require physical hardware for specific use cases. Starting in Phase 3, Kasha will offer optional hardware through partnerships:

• Bluetooth card readers: Compact readers (e.g., Adyen S1F2L) for merchants who want a dedicated device for chip-and-PIN or magstripe fallback
• Bluetooth thermal printers: 58mm/80mm receipt printers for merchants who need physical receipts (restaurants, retail)
• Customer-facing displays: Small screens showing transaction amount, payment confirmation, and branding
• Cash drawer integration: For merchants who still handle cash alongside digital payments — drawer opens automatically on cash tender

All hardware will be optional add-ons, never mandatory. The core value proposition remains zero-hardware payment acceptance.

Terminal Entity Model

Every terminal — whether a SoftPOS device (iPhone), a static QR code, or a physical card reader — is registered, tracked, and managed as a first-class entity in the system.

// src/modules/terminal/terminal.interface.ts

interface ITerminal {
  /** Unique terminal identifier (UUID v4) */
  id: string;

  /** Reference to the owning merchant */
  merchantId: string;

  /** Terminal type determines capabilities and payment methods */
  type: 'SOFTPOS_IOS' | 'SOFTPOS_ANDROID' | 'QR_STATIC' | 'QR_DYNAMIC' | 'CARD_READER';

  /** Current operational status */
  status: 'ACTIVE' | 'INACTIVE' | 'SUSPENDED';

  /** Device metadata (populated for SoftPOS and card readers) */
  deviceInfo?: {
    model: string;       // e.g., "iPhone 15 Pro", "Galaxy S24"
    os: string;          // e.g., "iOS 18.2", "Android 15"
    appVersion: string;  // e.g., "1.4.2"
  };

  /** Timestamp of the most recent transaction on this terminal */
  lastTransactionAt?: Date;

  /** Lifetime transaction count for this terminal */
  totalTransactions: number;

  /** When this terminal was first registered */
  createdAt: Date;
}

Terminal management capabilities include:

• Remote status control: Suspend or deactivate terminals from the admin dashboard (e.g., if a device is reported stolen)
• Version tracking: Monitor app versions across the fleet to ensure merchants are running compatible software
• Activity monitoring: Detect inactive terminals (no transactions in 30+ days) and trigger re-engagement flows
• Multi-terminal support: A single merchant can register multiple terminals (e.g., one iPhone per checkout lane)

Note Brazilian card settlements have a T+30 standard timeline from the acquirer. The T+1 payout shown above is achieved through Kasha's anticipation engine (Section 9), which advances receivables at a 1-2% discount.

Currency Architecture

Kasha's treasury operates on a country-contained model — each country maintains its own currency and settlement infrastructure with no cross-currency settlement required between countries.

• No cross-currency settlement: CH operations are entirely in CHF, BR operations entirely in BRL. This simplifies treasury management and eliminates FX risk at the platform level.
• FX at PSP level: When a tourist in Zurich pays with a USD Visa card, Adyen handles the USD → CHF conversion. Kasha and the merchant only ever see CHF.
• BRZ stablecoin option: Brazilian merchants can opt to receive settlement in BRZ (a BRL-pegged stablecoin) via Transfero, providing exposure to the crypto ecosystem while maintaining BRL-equivalent value.

Automated Three-Way Matching

The reconciliation engine performs automated matching across three data sources to ensure every cent is accounted for:

The reconciliation process runs automatically on a daily schedule:

• Transaction ↔ PSP matching: Every POS transaction is matched against the corresponding PSP settlement record using the unique transaction reference (PSP reference ID). Validates that the settled amount equals the expected amount minus fees.
• PSP ↔ Bank matching: PSP settlement batches are matched against incoming credits on Kasha's bank statements. Ensures that the total settled by the PSP matches the total credited to the bank account.
• Discrepancy handling: Any mismatches (amount differences, missing settlements, duplicate entries) are automatically flagged and queued for manual review by the operations team.
• Daily reports: Automated reconciliation reports generated each morning covering the previous day's settlements, including match rate, discrepancy count, and outstanding items.

Settlement Architecture Overview

Module Structure

lr-pos-service/
├── src/
│   ├── main.ts                          # Bootstrap, RabbitMQ consumer (LR_POS_SERVICE queue)
│   ├── config/
│   │   ├── config.ts                    # registerAs('app'), env vars
│   │   ├── config.module.ts             # Joi validation, defaults
│   │   └── config.service.ts            # Typed config getters
│   ├── modules/
│   │   ├── app.module.ts                # Root module
│   │   ├── health/                      # Health check (heap memory)
│   │   ├── merchant/                    # Merchant onboarding, KYB, sub-accounts
│   │   │   ├── merchant.interface.ts    # IMerchant, ICreateMerchantDto, enums
│   │   │   ├── merchant.entity.ts       # TypeORM: pos_merchants table
│   │   │   ├── merchant.service.ts      # CRUD + status transitions
│   │   │   ├── merchant.controller.ts   # @MessagePattern RPC handlers
│   │   │   └── merchant.module.ts
│   │   ├── terminal/                    # SoftPOS registration, QR terminal mgmt
│   │   ├── transaction/                 # Payment processing orchestration
│   │   ├── session/                     # POS session lifecycle (NEW)
│   │   │   ├── session.interface.ts     # ISession, SessionStatus enum
│   │   │   ├── session.entity.ts        # pos_sessions table
│   │   │   ├── session.service.ts       # Create, addItems, setAmount, complete
│   │   │   └── session.controller.ts    # RPC: pos_create_session, pos_add_items, etc.
│   │   ├── settlement/                  # Payout scheduling, bank transfers
│   │   ├── anticipation/                # Payment anticipation (credit) engine
│   │   ├── reconciliation/              # Match transactions ↔ settlements
│   │   ├── webhook/                     # Adyen + Transfero webhook handlers (HTTP)
│   │   └── analytics/                   # Sales reports, payment method breakdown
│   ├── providers/
│   │   ├── adyen/                       # Adyen SDK wrapper
│   │   ├── transfero/                   # Transfero API wrapper
│   │   └── banking/                     # Direct IBAN settlement (SIC)
│   └── common/
│       └── services/
│           └── rabbitmq-clients.ts      # ClientProxy providers
├── test/
│   └── bootstrap.ts
├── Dockerfile                           # Multi-stage (dev/prod)
├── package.json
└── tsconfig.json

Key Entities

NEW pos_sessions — Central Session Entity

Every payment interaction starts as a session. Sessions link to bookings, invoices, CRM customers, and catalogue line items.

@Entity('pos_sessions')
export class SessionEntity {
  @PrimaryGeneratedColumn('uuid') id: string;
  @Column('uuid') merchantId: string;
  @Column('uuid', { nullable: true }) terminalId: string;
  @Column('uuid', { nullable: true }) customerId: string;      // link to CRM
  @Column('uuid', { nullable: true }) bookingId: string;        // link to booking
  @Column('uuid', { nullable: true }) invoiceId: string;        // link to invoice
  @Column({ type: 'enum', enum: SessionStatus }) status: SessionStatus;
  @Column({ type: 'enum', enum: SessionType }) type: SessionType;
    // WALK_IN, BOOKING_DEPOSIT, BOOKING_FINAL, CATALOGUE_SALE
  @Column('jsonb', { nullable: true }) lineItems: ILineItem[];  // items from catalogue
  @Column('decimal', { precision: 12, scale: 2 }) amount: number;
  @Column('decimal', { precision: 12, scale: 2, default: 0 }) depositAmount: number;
  @Column('varchar', { length: 3 }) currency: string;           // CHF or BRL
  @Column({ type: 'enum', enum: PaymentMethod, nullable: true }) paymentMethod: PaymentMethod;
  @Column('uuid', { nullable: true }) transactionId: string;    // link to pos_transactions
  @CreateDateColumn() createdAt: Date;
  @UpdateDateColumn() updatedAt: Date;
}

pos_merchants

Merchant onboarding and KYB state.

id (uuid PK) | businessId (uuid) | legalName (varchar) | tradingName (varchar)
country (enum: CH, BR) | taxId (varchar) | kybStatus (enum) | adyenSubAccountId (varchar)
transferoMerchantId (varchar) | bankAccount (jsonb) | status (enum) | createdAt | updatedAt

pos_transactions

Individual payment records linked to sessions and terminals.

id (uuid PK) | merchantId (uuid) | terminalId (uuid) | sessionId (uuid)
amount (decimal 12,2) | currency (varchar 3) | paymentMethod (enum)
status (enum: PENDING, AUTHORIZED, CAPTURED, FAILED, REFUNDED)
pspReference (varchar) | pspProvider (enum: ADYEN, TRANSFERO)
refundedAmount (decimal 12,2) | metadata (jsonb) | createdAt | updatedAt

pos_terminals

Registered payment acceptance devices.

id (uuid PK) | merchantId (uuid) | type (enum: SOFTPOS, QR_STATIC, QR_DYNAMIC)
label (varchar) | deviceFingerprint (varchar) | status (enum: ACTIVE, INACTIVE, SUSPENDED)
lastActivityAt (timestamp) | totalVolume (decimal 14,2) | createdAt | updatedAt

pos_settlements

Scheduled and completed payouts to merchant bank accounts.

id (uuid PK) | merchantId (uuid) | amount (decimal 12,2) | currency (varchar 3)
status (enum: PENDING, PROCESSING, COMPLETED, FAILED) | scheduledDate (date)
completedAt (timestamp) | bankReference (varchar) | transactionIds (uuid[]) | createdAt

pos_anticipations

Receivables advance requests and disbursements.

id (uuid PK) | merchantId (uuid) | grossAmount (decimal 12,2) | feeAmount (decimal 12,2)
netAmount (decimal 12,2) | feeRate (decimal 5,4) | status (enum: REQUESTED, APPROVED, DISBURSED, REJECTED)
receivableIds (uuid[]) | disbursedAt (timestamp) | createdAt | updatedAt

pos_reconciliations

Transaction-to-settlement matching records.

id (uuid PK) | transactionId (uuid) | settlementId (uuid) | status (enum: MATCHED, UNMATCHED, DISPUTED)
pspAmount (decimal 12,2) | settledAmount (decimal 12,2) | discrepancy (decimal 12,2) | createdAt

RPC Endpoints @MessagePattern

All handlers use @MessagePattern decorators. No HTTP verbs — the API Gateway translates REST to RPC.

Webhook Controller HTTP Exception

Webhooks from Adyen and Transfero are the sole exception to the pure-RPC pattern. External PSPs POST notifications directly to HTTP endpoints, so these controllers use standard @Post() decorators. The API Gateway proxies these requests through to lr-pos-service without RabbitMQ translation.

@Controller('webhooks')
export class WebhookController {
  @Post('adyen')
  async handleAdyen(@Body() notification: AdyenNotification) {
    // Verify HMAC signature
    // Update transaction status (AUTHORIZED, CAPTURED, FAILED, REFUNDED)
    // Emit pos.payment.completed event
  }

  @Post('transfero')
  async handleTransfero(@Body() notification: TransferoNotification) {
    // Verify webhook signature
    // Update Pix payment status
    // Emit pos.payment.completed event
  }
}

Inter-Service Events RabbitMQ

Page Structure

src/app/[lang]/
├── dashboard/page.tsx       # Today's sales, payment breakdown, settlement status
├── transactions/page.tsx    # Live feed with filtering (card, Pix, TWINT, QR)
├── sessions/page.tsx        # Active POS sessions, session history
├── anticipation/page.tsx    # Available receivables, request advance, active loans
├── terminals/page.tsx       # Registered devices, status, last activity
├── settlement/page.tsx      # Bank account, upcoming/completed payouts
└── settings/page.tsx        # Payment methods config, IBAN, Pix keys, profile

Key Components

Services Layer Fetch Wrapper Pattern

Each domain has a dedicated service file that wraps the @kashatech/lr-fe-framework request helper. Services are pure functions — no state, no hooks. They map 1:1 to API Gateway endpoints.

// src/services/sessions.service.ts

export const createSession = async ({ businessId, data }) => {
  return await request.post({
    path: `/businesses/${businessId}/pos/sessions`,
    config: { data },
  });
};

export const addSessionItems = async ({ businessId, sessionId, items }) => {
  return await request.post({
    path: `/businesses/${businessId}/pos/sessions/${sessionId}/items`,
    config: { data: { items } },
  });
};

export const completeSession = async ({ businessId, sessionId, paymentMethod }) => {
  return await request.post({
    path: `/businesses/${businessId}/pos/sessions/${sessionId}/complete`,
    config: { data: { paymentMethod } },
  });
};

export const getSessions = async ({ businessId, params }) => {
  return await request.get({
    path: `/businesses/${businessId}/pos/sessions`,
    config: { params },
  });
};

Hooks Layer React Query Pattern

Custom hooks wrap the service functions with React Query for caching, background refetching, and optimistic updates. Query keys follow the [DOMAIN_KEY, { filters }] convention for targeted invalidation.

// src/hooks/use-sessions.ts

const SESSIONS_QUERY_KEY = 'pos-sessions';

export const useSessions = (status?: SessionStatus) => {
  const { businessId } = useBusinessContext();
  const { data, isLoading, isFetching } = useQuery({
    queryKey: [SESSIONS_QUERY_KEY, { businessId, status }],
    queryFn: () => getSessions({ businessId, params: { status } }),
    enabled: !!businessId,
  });
  return { sessions: data?.data ?? [], isLoading, isFetching };
};

export const useCreateSession = () => {
  const { businessId } = useBusinessContext();
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: (data: ICreateSessionDto) =>
      createSession({ businessId, data }),
    onSuccess: () =>
      queryClient.invalidateQueries({ queryKey: [SESSIONS_QUERY_KEY] }),
  });
};

export const useCompleteSession = () => {
  const { businessId } = useBusinessContext();
  const queryClient = useQueryClient();
  return useMutation({
    mutationFn: ({ sessionId, paymentMethod }: ICompleteSessionDto) =>
      completeSession({ businessId, sessionId, paymentMethod }),
    onSuccess: () => {
      queryClient.invalidateQueries({ queryKey: [SESSIONS_QUERY_KEY] });
      queryClient.invalidateQueries({ queryKey: ['pos-transactions'] });
    },
  });
};

REST Endpoints

Gateway Implementation Pattern

Each route follows the same pattern: extract path parameters and body, send an RPC message to the LR_POS_SERVICE queue via ClientProxy, and return the result. Authentication middleware validates the JWT and attaches the business context before the route handler.

// lr-api-gateway/src/modules/pos/pos.routes.ts

router.post('/businesses/:businessId/pos/sessions', async (req, res) => {
  const result = await rabbitMQClient.send(
    { cmd: 'pos_create_session' },
    { ...req.body, businessId: req.params.businessId }
  );
  res.json(result);
});

router.post('/businesses/:businessId/pos/sessions/:sessionId/items', async (req, res) => {
  const result = await rabbitMQClient.send(
    { cmd: 'pos_add_session_items' },
    { ...req.body, businessId: req.params.businessId, sessionId: req.params.sessionId }
  );
  res.json(result);
});

router.post('/businesses/:businessId/pos/sessions/:sessionId/complete', async (req, res) => {
  const result = await rabbitMQClient.send(
    { cmd: 'pos_complete_session' },
    { ...req.body, businessId: req.params.businessId, sessionId: req.params.sessionId }
  );
  res.json(result);
});

router.get('/businesses/:businessId/pos/transactions', async (req, res) => {
  const result = await rabbitMQClient.send(
    { cmd: 'pos_get_transactions' },
    { businessId: req.params.businessId, ...req.query }
  );
  res.json(result);
});

Webhook Routes Direct HTTP Passthrough

Webhook endpoints bypass the RabbitMQ RPC pattern entirely. External PSPs (Adyen, Transfero) POST notifications directly to these URLs. The API Gateway proxies these requests through to the lr-pos-service webhook controller over HTTP, not RabbitMQ.

POST /webhooks/pos/adyen      → lr-pos-service webhook controller (Adyen notifications)
POST /webhooks/pos/transfero  → lr-pos-service webhook controller (Transfero/Pix notifications)

These routes are unauthenticated at the JWT level but verified via PSP-specific HMAC signatures within the webhook controller itself.

New Luma Tools for POS

Luma Quick Action Chips POS Context

When a merchant is on the POS dashboard, Luma detects the page context and displays relevant quick-action chips. These are pre-built prompts that the merchant can tap to instantly query common POS data without typing.

Example Conversation

A typical merchant interaction with Luma on the POS dashboard:

Tool Registration Pattern

POS tools are registered in lr-luma-service following the existing tool provider pattern. Each tool defines its name, description, parameter schema, and an execute function that sends an RPC call to lr-pos-service and formats the response for the LLM.

// lr-luma-service/src/tools/pos/pos-get-sales.tool.ts

export const posGetSalesTool: LumaTool = {
  name: 'pos_get_sales',
  description: 'Get sales summary for the merchant. Returns total revenue, ' +
    'transaction count, and breakdown by payment method for a given date range.',
  parameters: {
    type: 'object',
    properties: {
      dateFrom: { type: 'string', format: 'date', description: 'Start date (ISO)' },
      dateTo:   { type: 'string', format: 'date', description: 'End date (ISO)' },
    },
  },
  actionType: 'read',
  async execute(params, context) {
    const result = await rabbitMQClient.send(
      { cmd: 'pos_get_sales_summary' },
      { merchantId: context.merchantId, ...params }
    );
    return formatSalesSummary(result);
  },
};

Phase 1 Foundation — Months 1–2

The minimum viable product. Everything a merchant needs to accept their first payment and see their money. Ship fast, prove the model, get merchants live.

• Core POS session lifecycle: create → pay → receipt
• Adyen integration: card payments CH, TWINT CH
• Transfero integration: Pix QR payments BR
• Basic merchant onboarding (manual KYB)
• SoftPOS: Apple Tap to Pay CH
• Simple transaction list + daily summary
• Receipt generation (digital)
• lr-pos-service + lr-pos-ui deployed
• API Gateway routes added

Phase 1 Deliverables

Phase 2 Growth — Months 3–4

The revenue phase. Payment anticipation lands as the killer feature for Brazil. New payment methods expand coverage. Cross-module integrations start connecting POS to the rest of the Kasha platform.

• Payment anticipation engine BR — Killer Feature
• Pix Tap to Pay BR
• PostFinance Card CH
• Open Banking / SIC settlement CH
• Booking integration (deposit collection, final payments)
• Invoice auto-generation from POS sessions
• Settlement dashboard with payout tracking
• CRM integration (link payments to customers)

Phase 3 Expansion — Months 4–6

Deepening the platform. Catalogue integration turns POS into a lightweight retail system. New payment methods (Boleto, BRZ stablecoin) round out coverage. Analytics become actionable.

• Catalogue integration (light stock management)
• Barcode/SKU scanning in POS session
• Boleto payments BR
• BRZ stablecoin settlement BR
• Advanced analytics (revenue trends, payment mix, top products)
• Multi-terminal support per merchant
• Automated reconciliation engine
• Merchant self-service onboarding (automated KYB via Adyen)

Phase 4 Credit & Advanced — Months 6–9

Financial services layer. Adyen Capital unlocks merchant lending in Switzerland (requires 4+ months of transaction history per client). Crypto payments via Transfero open a new channel. Risk scoring matures.

• Adyen Capital integration CH — requires 4+ months tx history per client
• Crypto payments via Transfero (BTC/ETH → BRZ auto-convert) BR
• Advanced risk scoring for anticipation
• Hardware terminal partnerships (optional Bluetooth readers)
• Customer-facing payment page (QR code links to payment form)
• Luma AI full integration (all POS tools)

Phase 5 Scale — Months 9–12

Platform maturity. Multi-location support, franchise management, white-label capabilities, and marketplace settlement transform Kasha POS from a single-merchant tool into an enterprise-grade platform.

• Multi-location merchant support
• Franchise / chain management
• Advanced reporting and exports
• White-label POS for partners
• Marketplace settlement (multi-vendor)
• International card acceptance optimization
• Performance optimization for high-volume merchants

Timeline Overview

CH Switzerland

• FINMA — Financial Market Supervisory Authority. Kasha needs appropriate licensing for payment services. FINMA regulates all financial intermediaries in Switzerland, including payment service providers.
• PCI DSS — Payment Card Industry Data Security Standard. Required for card acceptance. Level 4 merchant (< 1M txns/year) needs SAQ-A or SAQ-B depending on integration method.
• PCI MPoC — Mobile Payment on COTS (Commercial Off-The-Shelf). Required for SoftPOS (Apple Tap to Pay). Adyen handles this via their certified SDK, which has passed MPoC evaluation.
• FADP (nDSG) — Swiss Federal Act on Data Protection. Data localization is not strictly required but recommended. Customer data handling must comply with the revised FADP that entered into force September 2023. Consent management, data minimization, and breach notification obligations apply.
• TWINT Terms — TWINT AG participation requirements via Adyen. Adyen is an authorized TWINT acquirer, so Kasha merchants are onboarded through Adyen's TWINT integration without needing direct TWINT AG agreements.
• AML/KYC — Anti-Money Laundering requirements for merchant onboarding. Beneficial ownership declaration required. Swiss AML Act (AMLA/GwG) applies to all financial intermediaries. Adyen handles merchant verification as the licensed acquirer.

BR Brazil

• BCB (Banco Central do Brasil) — Central Bank regulates all payment institutions. Pix regulations apply to all participants in the Pix ecosystem. Transfero is a licensed payment institution, so Kasha operates under Transfero's regulatory umbrella for Pix services.
• PCI DSS — Same global standard, enforced by card brands (Visa, Mastercard) through local acquirers. Applies to any entity that stores, processes, or transmits cardholder data.
• PCI MPoC — Required for Pix Tap to Pay implementation. The NFC-based Pix payment acceptance on merchant phones must comply with COTS security standards.
• LGPD — Lei Geral de Proteção de Dados (Brazilian GDPR). Requires customer consent for data collection, data minimization principles, breach notification within reasonable time, and appointment of a Data Protection Officer (DPO). Fines up to 2% of revenue (capped at R$50M per infraction).
• Antecipação Regulations — BCB Resolution 264/2022. Rules for receivables registration and anticipation. Receivables must be registered in approved registrars (TAG, CIP, CERC). Merchants have the right to choose their anticipation provider. Transparent fee disclosure is mandatory.
• PIX Regulations — BCB rules for Pix participants. QR code standards (static and dynamic), settlement rules (instant, 24/7/365), dispute resolution (MED — Mecanismo Especial de Devolução), and transaction limits apply.
• CNPJ/CPF Requirements — Tax identification for merchants (CNPJ — Cadastro Nacional da Pessoa Jurídica) and customers (CPF — Cadastro de Pessoas Físicas). Required for all financial transactions and merchant onboarding in Brazil.

Compliance Matrix

Payment Acceptance

• Accept card payments (Visa, Mastercard, Amex)
• Accept TWINT payments CH
• Accept Pix payments via QR code BR
• Accept Pix Tap to Pay BR
• Accept Apple Tap to Pay on iPhone
• Accept PostFinance Card CH
• Accept open banking payments CH
• Accept Boleto BR
• Accept BRZ stablecoin BR
• Accept crypto (BTC/ETH via Transfero) BR
• Process refunds (full and partial)
• Handle chargebacks

POS Sessions

• Create walk-in payment sessions
• Create booking-linked deposit sessions
• Create booking final payment sessions
• Create catalogue-based sale sessions
• Add line items from catalogue
• Apply discounts
• Split payments (partial amounts)
• Link session to customer (CRM)
• Link session to booking
• Link session to invoice
• Generate digital receipts

Merchant Management

• Merchant registration and onboarding
• KYB verification (per country)
• PSP sub-merchant account creation
• Bank account / Pix key management
• Payment method configuration
• Business profile management

Terminal Management

• Register SoftPOS devices (iPhone)
• Generate static QR codes
• Generate dynamic QR codes per transaction
• Monitor terminal status and health
• Track terminal transaction volume

Settlement & Treasury

• Automated payout scheduling
• Multi-currency settlement (CHF, BRL)
• Real-time settlement tracking
• Bank transfer via SIC CH
• Pix instant settlement BR
• BRZ stablecoin settlement BR
• Settlement reconciliation

Payment Anticipation (Credit)

• View available receivables BR
• Calculate anticipation fees
• Risk scoring (in-house) BR
• Request receivables advance BR
• Next-day disbursement via Pix BR
• Adyen Capital merchant lending CH Phase 4
• Anticipation history and reporting

Analytics & Reporting

• Real-time sales dashboard
• Payment method breakdown
• Daily / weekly / monthly trends
• Top products (with catalogue)
• Settlement reports
• Reconciliation reports
• Export to CSV / PDF

Cross-Module Integration

• Auto-generate invoices from POS sessions
• Sync with booking deposits and final payments
• Decrement catalogue stock on sale
• Update CRM customer purchase history
• Luma AI query and action tools
• Banking service payout integration