Payment Processing

The Payment Problem in Experience Hospitality

Payment collection in experience hospitality is fundamentally different from e-commerce or subscription billing. An e-commerce transaction is a single payment at checkout. A SaaS subscription is a recurring charge on a fixed schedule. A surf camp booking is a multi-stage financial conversation: a 30% deposit at booking, a balance payment 30 days before arrival, potential add-on charges during the stay (equipment rental, extra activities, bar tab), and possibly a partial refund after departure if a scheduled activity was cancelled due to weather.

Most operators handle this with a chaotic mix of payment methods. The deposit comes through Stripe on the website. The balance payment arrives as a bank transfer with a reference that may or may not match the booking number. The guest pays for the extra surf lesson with cash at the front desk. The partial refund for the cancelled boat trip is processed through PayPal because that's what the receptionist had open. The result is a reconciliation nightmare: four payment methods, three different systems, and a spreadsheet trying to track which booking has been fully paid.

Artidal's Payment Processing module unifies all payment collection through a single, Stripe-powered infrastructure that handles the complete payment lifecycle — from initial deposit through balance collection, on-property charges, and refunds — with real-time status updates, automatic reconciliation, and full audit trails.

Stripe Integration: Cards, Bank Transfers, and Local Methods

The module integrates with Stripe as the primary payment infrastructure, providing access to card payments (Visa, Mastercard, Amex), bank transfers (SEPA Direct Debit for European guests, ACH for US guests), and local payment methods that vary by market — iDEAL for Dutch guests, Bancontact for Belgian guests, Przelewy24 for Polish guests, and BLIK for the growing Polish surf tourism segment.

Local payment methods matter more than most operators realise. Conversion rate data consistently shows a 20-30% improvement when guests can pay with their preferred local method rather than entering card details on an unfamiliar website. A Dutch guest booking a Portuguese surf camp is significantly more likely to complete the booking if they can pay with iDEAL — a bank-redirect method that 60% of Dutch online payments use — than if they're forced to enter credit card details.

Stripe's payment method coverage continues to expand, and Artidal passes through new methods as Stripe adds them. This means operators gain access to additional payment methods (like Pix in Brazil, Konbini in Japan, or PromptPay in Thailand) without any development work — Stripe activates the method, and Artidal surfaces it to guests from the relevant market based on their billing address or browser locale.

Multiple Payment Providers Per Company

Experience hospitality businesses often operate across multiple legal entities, brands, or locations — each of which may need its own payment processing account for legal, regulatory, or financial reasons. A group running surf camps under two brands (a premium brand and a budget brand) in three countries (Portugal, Morocco, Indonesia) might have six separate Stripe accounts — one per brand per country — each connected to a local bank account in the local currency.

Artidal supports multiple Stripe Connect accounts per company, with automatic routing based on the booking's brand and location. When a guest books the premium Bali experience, the payment flows to the Bali premium Stripe account and settles in the designated bank account. When another guest books the budget Morocco camp, the payment routes to the Morocco budget account. The operator manages all accounts from a single dashboard, with consolidated reporting across all providers.

This multi-provider architecture also enables future expansion to additional payment processors beyond Stripe. While Stripe covers the vast majority of use cases, some markets (particularly in Southeast Asia and Latin America) have local payment processors with better rates or broader coverage. The architecture supports adding alternative processors without changing the booking flow or guest experience.

Deposit and Full Payment Logic

The booking payment flow supports configurable deposit and balance payment schedules. Operators define the deposit percentage (typically 20-50% for experience hospitality), the balance payment deadline (commonly 30-60 days before arrival), and the consequences of non-payment (automatic cancellation after a grace period, or manual follow-up via the communication module).

When a guest books and pays the deposit, the system creates a payment schedule for the remaining balance. Automated reminders are sent at configurable intervals — 60 days before arrival (friendly reminder), 30 days before (balance now due), 15 days before (final notice), and 7 days before (auto-cancellation warning). Each reminder includes a secure payment link that pulls up the outstanding balance with the guest's saved payment details, reducing payment friction to a single click.

The deposit-to-balance flow handles edge cases that trip up simpler payment systems: what happens when a guest modifies the booking after paying the deposit (the balance amount recalculates automatically), what happens when the exchange rate changes between deposit and balance payment (each payment locks its own exchange rate), and what happens when a guest wants to pay the full amount upfront instead of following the deposit schedule (the system accepts full payment and marks the payment schedule complete).

Partial Payment Matching

Bank transfers are a preferred payment method for many European guests, particularly for high-value bookings. But bank transfers create a reconciliation challenge: the guest sends money from their bank, the transfer arrives 1-3 business days later with a reference that may be the booking number, the guest's name, a truncated version of either, or something entirely unrelated that the guest typed into the reference field.

Artidal's partial payment matching engine addresses this with a multi-signal approach. Incoming bank transfers (reported by Stripe or imported from bank statements) are matched against outstanding invoices using: the transfer reference (fuzzy-matched against booking numbers and invoice numbers), the amount (exact match or partial match against the outstanding balance), the sender name (matched against the guest's profile name and payment history), and the currency (confirming the transfer currency matches the invoice currency).

When a high-confidence match is found (reference + amount + currency all align), the payment is applied automatically. When the match is ambiguous (amount matches but reference doesn't), the payment is flagged for manual review with the top candidate invoices pre-selected. When no match is found, the payment enters an unmatched queue for staff assignment. This tiered approach automates 70-80% of bank transfer reconciliation while ensuring human oversight for edge cases.

Webhook-Based Real-Time Status

Payment status in Artidal is updated in real time via Stripe webhooks — not by polling, not by manual entry, and not by a nightly batch reconciliation. When a card payment succeeds, when a bank transfer lands, when a dispute is opened, or when a refund completes, Stripe sends a webhook event to Artidal, which updates the payment status, invoice status, and booking status within seconds.

This real-time status propagation has practical implications throughout the operator's workflow. The front desk knows immediately when a guest's balance payment has cleared (without checking the bank account manually). The automated communication module can trigger a 'payment received' confirmation email within minutes of the payment landing. The booking status updates from 'balance pending' to 'fully paid' without staff intervention. And the financial dashboard reflects the current cash position accurately, not yesterday's position from the last manual reconciliation.

Webhook reliability is critical for payment systems. Artidal implements Stripe's recommended webhook verification (signature checking with the endpoint secret), idempotent event processing (the same webhook delivered twice doesn't double-count the payment), and automatic retry handling (if the webhook endpoint is temporarily unavailable, Stripe retries with exponential backoff, and Artidal processes the events in order when they arrive). For PCI DSS compliance, webhook payloads never contain raw card data — only tokenized references, transaction IDs, and status metadata.

Security and Compliance

Payment processing sits at the intersection of two demanding compliance frameworks: PCI DSS (Payment Card Industry Data Security Standard) and GDPR (General Data Protection Regulation). Artidal's architecture handles both by delegating sensitive data to Stripe and retaining only the metadata needed for financial management.

PCI DSS compliance is achieved through Stripe Elements — the card input fields are rendered in Stripe-hosted iframes, so card numbers, CVVs, and expiration dates never touch Artidal's servers. This qualifies operators for SAQ-A (the simplest PCI self-assessment), avoiding the cost and complexity of SAQ-D compliance that would be required if Artidal handled card data directly. Operators don't need to maintain PCI-scoped infrastructure, undergo quarterly network scans, or implement card-data encryption — Stripe's infrastructure handles all of that.

GDPR compliance for payment data follows the principle of data minimisation. Artidal stores the minimum payment metadata required for financial operations: transaction ID, amount, currency, status, payment method type (card, bank transfer, iDEAL), and the last four digits of the card (for guest recognition and dispute handling). Full card data, bank account numbers, and authentication credentials are stored exclusively in Stripe's PCI-compliant vault. When a guest exercises data erasure rights, Artidal removes personal identifiers from payment records while preserving the anonymised financial data required for tax and accounting obligations.

For operators in Costa Rica, the CRC's regulatory environment adds another layer: the Banco Central de Costa Rica (BCCR) regulates foreign-currency transactions, and operators must report income in colones for tax purposes even when collecting in USD. Artidal's integration with Stripe handles the USD collection while the financial management module records the CRC-equivalent at the BCCR reference rate on the transaction date — satisfying both the guest's expectation of paying in dollars and the regulatory requirement to report in the local currency.