When to Use Link Pay
- Best For
- Not Suitable For
Ideal use cases:
- User interacts through a mobile app or mobile web flow
- Merchant wants to offload the payment UI to Rebell
- Flow requires strong user authentication within the SuperApp
- Checkout should redirect seamlessly to Rebell and return afterward
- App-based purchases
- Web checkout (scan-to-app or auto redirect)
- Subscription or recurring services (first-time payment)
- On-demand services (mobility, taxis, ride-hailing)
- Digital goods or top-up flows
Payment Flow
1
User Initiates Checkout
User initiates checkout in the merchant app or website
2
Create Link Pay Order
Merchant backend calls Rebell
linkPayCreate API3
Receive Redirect URLs
Rebell responds with:
- A redirect URL (deep link)
- App-to-app deep links (Android / iOS)
- Optional fallback links (browser-based)
4
Redirect User
Merchant redirects the user to Rebell using the appropriate link
5
User Confirms Payment
User reviews and confirms payment inside the Rebell SuperApp
6
Process Payment
Rebell processes the transaction
7
Webhook Notification
Merchant receives webhook notification with the final payment status
8
Complete Order
Merchant app or website updates the UI and completes the order
Sequence Diagram
API Specification
Endpoint
Request Headers
Include standard authentication headers:Request Body
Payment product type assigned by Rebell
Merchant-generated unique ID (idempotency key). Must be unique per transaction.
Payment amount details
Order details
Settlement configuration
Response Parameters
Result details
Deep link to open Rebell SuperApp directly
Platform-specific app link metadata
Payment identifier to be used for inquiry or reconciliation
Redirect Logic
- Mobile App (Native)
- Mobile Browser
- Desktop Browser
For users on native mobile apps:Use one of the following:
redirectUrl(deep link)appLinks.android.shortUrl(Android)appLinks.ios.shortUrl(iOS)
Merchant Behavior Rules
Merchant MUST
Merchant MUST NOT
Handling Payment Completion
Upon Receiving Webhook SUCCESS
Payment completed successfullyActions to take:
- Mark order as PAID in your system
- Redirect user to success screen
- Trigger fulfillment flow
- Send confirmation to customer
Upon Receiving Webhook FAIL
Error Scenarios & Recovery
ORDER_STATUS_INVALID
ORDER_STATUS_INVALID
Cause: Order in invalid or closed stateRecovery:
- Generate a new
paymentRequestId - Ensure backend order lifecycle is correct
- Verify order hasn’t already been paid or canceled
PAYMENT_IN_PROCESS
PAYMENT_IN_PROCESS
Cause: Another payment is already processing for the same requestRecovery:
- Use inquiry API to check existing payment status
- Prevent duplicate link generation
- Wait for the current payment to complete or fail
NEED_RISK_CHALLENGE
NEED_RISK_CHALLENGE
Cause: User must complete additional verification inside RebellRecovery:
- Display: “Please complete verification in Rebell”
- Wait for webhook notification
- Do not retry or create new payment request
PROCESS_FAIL
PROCESS_FAIL
Cause: Internal processing failureRecovery:
- Retry with the same
paymentRequestId(idempotent) - If retries fail, wait and try again later
- Contact support if issue persists
User Returns Without Completing
User Returns Without Completing
Cause: User closed the app or navigated away before completingRecovery:
- Check payment status via inquiry API
- If still pending, allow user to retry redirect
- Payment may still complete via webhook
Security Considerations
UX Recommendations
Create optimal experiences based on the user’s context:- Mobile Apps
- Websites
- Messaging
For merchant mobile apps:
- Auto-redirect without confirmation prompt
- Show loading spinner until redirect is handled
- After return, display pending state until webhook arrives
- Handle app-not-installed gracefully
Implementation Example
Here’s a complete implementation example:Complete Flow Example