Payment Providers
Understanding the different payment methods and providers supported by Rahal
Payment Providers
Rahal supports multiple payment providers to accommodate different user needs and booking contexts. Each provider has its own flow, fee structure, and use case.
Supported Providers
| Provider | Description | Use Case |
|---|---|---|
SUPER_QI_APP | Super Qi mobile wallet | Consumer bookings in Iraq |
CHECKOUT_COM | Card payments via Checkout.com | Card payments |
BNPL | Buy Now, Pay Later | Installment payments |
SANDBOX | Test/sandbox payments | Development and testing |
CORPORATE_DIRECT | Company billing | Corporate travel bookings |
Provider Details
SUPER_QI_APP
The primary payment method for consumer bookings in Iraq using the Super Qi mobile wallet.
Flow:
- Order created → Payment session initiated
- User redirected to Super Qi app
- User approves payment in wallet
- Webhook confirms payment → Order processed
Features:
- Mobile wallet integration
- Instant payment verification
- User-friendly for Iraqi market
CHECKOUT_COM
Credit/debit card payments processed through Checkout.com.
Flow:
- Order created → Checkout.com session created
- User enters card details in hosted form
- Payment processed → 3DS if required
- Payment confirmed → Order processed
Features:
- Supports major card networks (Visa, Mastercard)
- 3D Secure authentication
- PCI-compliant card handling
BNPL (Buy Now, Pay Later)
Installment payment option allowing users to pay over time.
Flow:
- Order created → BNPL eligibility checked
- User confirms installment plan
- First installment processed
- Order processed → Remaining installments scheduled
Features:
- Split payments over multiple months
- Additional fee percentage applied
- Eligibility requirements apply
Fee Structure:
Original Price + (Original Price × Fee Percentage) = Total PriceThe fee percentage is configured at the system level. When viewing orders, both the base amount and BNPL fee are displayed.
BNPL orders show isPaid: false until all installments are confirmed. The initial PAID status reflects the first installment only.
SANDBOX
Test payment provider for development and testing environments.
Flow:
- Order created with test payment ID
- Payment automatically marked as successful
- Order processed normally
Features:
- No actual payment processing
- Instant verification
- Available in development/staging only
SANDBOX should never be available in production. It bypasses all payment verification.
CORPORATE_DIRECT
Special provider for corporate travel where the company is billed directly.
Flow:
- Policy and budget evaluation
- Order created (no payment required)
- Budget reserved
- Reservations created
- Budget confirmed on success
Features:
- No user payment required
- Company invoiced separately
- Integrated with policies and budgets
- Detailed audit trail
See Corporate Direct for complete details.
Provider Selection
The payment provider is determined at order creation based on:
- User Context: Consumer vs. corporate user
- Platform: Which app/platform initiated the booking
- User Selection: Which payment method the user chose
Provider by Platform
| Platform | Available Providers |
|---|---|
| Consumer App | SUPER_QI_APP, CHECKOUT_COM, BNPL |
| Corporate App | CORPORATE_DIRECT |
| Travel Zone Web | SUPER_QI_APP, CHECKOUT_COM |
Payment Verification
Each provider has its own verification mechanism:
| Provider | Verification Method |
|---|---|
| SUPER_QI_APP | API call to verify payment status |
| CHECKOUT_COM | Webhook callback from Checkout.com |
| BNPL | BNPL provider confirmation |
| SANDBOX | Always returns success |
| CORPORATE_DIRECT | Always returns success (no payment) |
Order Fields by Provider
When viewing orders, provider-specific fields are displayed:
| Field | SUPER_QI_APP | CHECKOUT_COM | BNPL | CORPORATE_DIRECT |
|---|---|---|---|---|
provider | SUPER_QI_APP | CHECKOUT_COM | BNPL | CORPORATE_DIRECT |
paymentId | Super Qi ID | Checkout.com ID | BNPL ID | Order ID |
bnplFeeAmount | 0 | 0 | > 0 | 0 |
bnplFeePercentage | 0 | 0 | > 0 | 0 |
companyId | null | null | null | Company ID |
policyId | null | null | null | Policy ID |
Transaction Records
Each successful payment creates a transaction record linking:
- Order reference
- Payment amount
- Payment timestamp
- Provider-specific payment ID
- BNPL installment ID (if applicable)
Refunds are linked to transactions, tracking:
- Refund amount
- External reference
- Refund reason
Error Handling
Payment failures are handled differently by provider:
SUPER_QI_APP
- User can retry in app
- Order remains in ACCEPTED until timeout
CHECKOUT_COM
- Error displayed to user
- User can retry with different card
- 3DS failures logged
BNPL
- Eligibility failures prevent order creation
- Installment failures logged for follow-up
CORPORATE_DIRECT
- Policy blocks: Order rejected with violation message
- Budget blocks: Order rejected with budget message