Wallet Top-Up
Overview
The Wallet Top-Up API allows you to initiate a top-up to your company's wallet using supported payment providers. The top-up process involves initiating a payment, redirecting the user to the payment provider's checkout page, and handling the asynchronous verification of the transaction.
Asynchronous Transaction Verification
When a top-up is initiated, a background job is dispatched to verify the transaction after a certain delay (e.g., 2 minutes). This means that the transaction status may not be immediately updated to "success" even after the payment is completed. You can use the Check Transaction Status endpoint to poll for the transaction status.
Endpoints
Top-Up Wallet
Initiate a wallet top-up for a company.
Endpoint:
/api/wallet/top-up
Method:
POST
Headers:
Authorization
String
Bearer token (Bearer {api_token}
)
Yes
Content-Type
String
application/json
Yes
Body Parameters:
amount
Float
The amount to top up (in NGN).
Yes
customer_email
String
The email of the customer initiating the top-up.
Yes
redirect_url
String
The URL to redirect to after the payment is completed. Must be a domain authorized by the company.
Yes
company_id
Int
ID of the company to top up the wallet for (defaults to authenticated company if not provided).
No
Notes:
Job Dispatching: Upon successful initiation, a background job is dispatched to verify the transaction after a delay (e.g., 2 minutes for Flutterwave, 5 minutes for Monnify). This handles asynchronous verification of the payment.
Success Response:
Code:
200 OK
Content:
Explanation:
checkoutUrl
: The URL where the user should be redirected to complete the payment.transactionReference
: A unique reference for the transaction, used for tracking and verification.
Error Responses:
400 Bad Request
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
Check Transaction Status
Check the status of a wallet transaction.
Endpoint:
/api/wallet/transaction/status
Method:
GET
Headers:
Authorization
String
Bearer token (Bearer {api_token}
)
Yes
Query Parameters:
transaction_reference
String
The transaction reference obtained when initiating the top-up.
Yes
company_id
Int
ID of the company to check the transaction for (optional).
No
Notes:
Transaction Statuses:
pending: The transaction is pending verification. This is common immediately after initiating the top-up or if the payment provider hasn't confirmed the payment yet.
success: The transaction has been successfully verified, and the wallet balance has been updated.
failed: The transaction failed or was canceled.
Success Response:
Code:
200 OK
Content:
Error Responses:
401 Unauthorized
403 Forbidden
404 Not Found
500 Internal Server Error
Transaction Verification Process
The transaction verification is handled asynchronously via background jobs. After initiating a top-up:
A background job is dispatched to verify the transaction after a delay.
The job checks the payment provider's API to confirm the payment status.
Once verified, the transaction status is updated accordingly in your wallet.
Implications:
Delayed Status Updates: The transaction status may remain as "pending" for a short period even after payment completion.
Polling for Status: Use the Check Transaction Status endpoint to poll for the updated status if needed.
No Immediate Confirmation: Do not assume the transaction is successful immediately after payment; always check the transaction status.
General Information
Notes
All timestamps are in ISO 8601 format (
YYYY-MM-DDTHH:MM:SSZ
).Error messages are designed to be clear and provide guidance on how to correct the issue.
Job Dispatching Context: Understanding that certain operations are handled asynchronously via background jobs is crucial for proper integration.
Common HTTP Status Codes
200 OK: The request was successful.
201 Created: The resource was created successfully.
400 Bad Request: The request was invalid or cannot be processed.
401 Unauthorized: Authentication failed or was not provided.
403 Forbidden: The user does not have permission to access the resource.
404 Not Found: The requested resource was not found.
422 Unprocessable Entity: Validation errors occurred.
429 Too Many Requests: Rate limit exceeded.
500 Internal Server Error: An unexpected error occurred on the server.
Rate Limiting
API endpoints may be subject to rate limiting. Exceeding the rate limit will result in a 429 Too Many Requests
response.
Examples
1. Initiating Wallet Top-Up with Job Dispatch Context
Request:
Response:
Explanation:
After receiving this response, redirect the user to the
checkoutUrl
to complete the payment.A background job has been dispatched to verify the transaction after a delay.
Use the
transactionReference
to check the transaction status later.
2. Checking Transaction Status
Request:
Response (Pending):
Response (Success):
Security Considerations
Authentication: Ensure that the
Authorization
header is included in every request that requires authentication.Authorization: Users can only manage resources for companies they are authorized to access.
Input Validation: Validate all inputs to prevent SQL injection and other malicious inputs.
Redirect URLs: For wallet top-ups, ensure that the
redirect_url
parameter points to a domain authorized by your company.Handling Asynchronous Operations: Be aware that certain operations are processed asynchronously. Design your application to handle delayed updates appropriately.
Best Practices
Handle Pending Transactions: Implement logic to handle transactions that are in a "pending" state, and inform users accordingly.
Use Webhooks (if available): If webhooks are provided, utilize them to receive real-time updates on transaction statuses.
Retry Logic: Implement retry mechanisms when polling for transaction status, with exponential backoff to avoid hitting rate limits.
Logging and Monitoring: Keep logs of transaction references and statuses for auditing and troubleshooting purposes.
Contact Support
If you encounter any issues or have questions about the API, please contact our support team at support@gangmates.com.
Disclaimer: This API reference is provided for informational purposes and may be subject to change. Please refer to the latest documentation available for the most up-to-date information.
Last updated