Skip to main content
The Payment service provides a mock payment processing implementation for testing and development. It simulates payment intent round-trips with realistic latency and random failure scenarios.

Types

PaymentResult

Discriminated union representing the outcome of a payment transaction.
type PaymentResult =
  | { success: true }
  | { success: false; error: string }
PaymentResult
union
Payment transaction result

Functions

processMockPayment

Simulates a payment intent with realistic latency (2 seconds) and a 15% random failure rate.
processMockPayment(amount: number): Promise<PaymentResult>
amount
number
required
Payment amount in currency units (currently not validated, reserved for future use)
result
PaymentResult
Payment outcome after 2-second delay

Example

import { processMockPayment } from '@/src/lib/core/payments/paymentService';

const result = await processMockPayment(45.50);

if (result.success) {
  console.log('Payment successful!');
  // Navigate to success screen
} else {
  console.error('Payment failed:', result.error);
  // Show error message to user
  alert(result.error);
}

Type guard usage

const result = await processMockPayment(totalAmount);

// TypeScript narrows the type based on success field
if (result.success) {
  // result is { success: true }
  showSuccessNotification();
} else {
  // result is { success: false; error: string }
  showErrorMessage(result.error);
}

Behavior

Latency simulation

All payment requests include a 2-second delay (setTimeout) to simulate network round-trip and payment processor latency.

Failure simulation

The service has a 15% random failure rate (Math.random() > 0.15). Failed payments return the following Spanish error message:
Lo sentimos, el banco rechazo la transaccion. Intenta con otro metodo.
This mock service is intended for development and testing only. Replace with a real payment processor (Stripe, PayPal, etc.) in production.

Production considerations

When replacing this service with a real payment processor:
  1. Maintain the same PaymentResult type signature for minimal refactoring
  2. Handle additional error cases (network failures, declined cards, etc.)
  3. Implement proper error logging and monitoring
  4. Add PCI compliance requirements
  5. Implement idempotency for retry scenarios