paymentAuthCode to create and authorize a payment request through Rebell’s Payment API.
This flow is designed for in-store payments, POS systems, kiosks, and any physical checkout environment where the merchant initiates the transaction.
When to Use Retail Pay
- Best For
- Not Suitable For
Ideal use cases:
- In-store POS systems with barcode scanners
- Mobile POS applications
- Self-service kiosks
- Physical checkout counters
- Fast, real-time authorization flows
- Alipay/WeChat “scan-to-pay” style experience
Payment Flow
User Displays Code
Customer opens the Rebell SuperApp and displays their dynamic payment code (QR or barcode)
Process Payment
Rebell processes the payment and returns:
SUCCESS(final)PROCESSING(requires polling)FAIL(rejected or invalid code)
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.
Dynamic code scanned from the user’s app
Payment amount details
Order details
Response Parameters
Payment result details
Rebell’s unique payment identifier (present on SUCCESS or PROCESSING)
Handling Response Status
When Rebell Returns SUCCESS
Payment is authorized and final
- Payment is complete and settled
- You may immediately print receipt and deliver goods
- No need to wait for webhook (though you’ll still receive one)
When Rebell Returns PROCESSING
Example Polling Logic
When Rebell Returns FAIL
Error Scenarios & Recovery
Invalid or Expired Payment Code
Invalid or Expired Payment Code
ResultCode:
INVALID_CODECause: The scanned paymentAuthCode is invalid or expiredRecovery:- Ask the user to refresh their payment code in the SuperApp
- Retry by scanning the new code
- Payment codes typically expire after 60 seconds
Risk Review Required
Risk Review Required
ResultCode:
NEED_RISK_CHALLENGECause: Rebell requires additional risk verificationRecovery:- Display on POS: “Please confirm the payment in your app”
- Wait for webhook notification or poll inquiry API
- User must approve payment in their SuperApp
User Rejected Payment
User Rejected Payment
ResultCode:
PAYMENT_REJECTEDCause: User explicitly denied the transaction in the appRecovery:- Inform customer that payment was declined
- Request alternative payment method
- Do not retry automatically
Timeout / Connection Issues
Timeout / Connection Issues
Cause: Network error or timeout during API callRecovery:
- Retry the request (safe due to
paymentRequestIdidempotency) - Never create a new
paymentRequestIdfor the same transaction - If retries fail, wait for webhook notification
Security Considerations
Best Practices
- Store
paymentAuthCodeonly temporarily during transaction - Log transaction attempts without exposing sensitive codes
- Implement device authentication for POS terminals
- Monitor for unusual scanning patterns or high failure rates
- Set transaction amount limits per merchant policy
UX Recommendations
Create a smooth checkout experience:Visual Confirmation
POS should visually confirm when scanning succeeded with clear feedback
Processing Indicator
If PROCESSING, show a spinner with “Awaiting confirmation…” message
Error Messages
Display clear, actionable error messages when codes are expired or unreadable
Timeout Handling
Avoid blocking the cashier longer than 30-40 seconds. Offer alternatives.
- Sound/vibration feedback when payment succeeds
- Automatic receipt printing on success
- Display payment amount before scanning for verification
Testing Checklist
Before going live, test these scenarios in sandbox:Next Steps
Inquiring Payment API
Learn how to poll payment status for PROCESSING transactions
Webhooks
Implement webhook handlers for final payment notifications
Error Handling
Complete reference for error codes and recovery strategies
QR Order Pay
Alternative flow where user scans merchant’s QR code