Approvals & Double Signature
Some payout transactions require additional authorization before they can be processed. This guide explains when authorization is needed and how to approve payouts through different methods.
When Authorization Is Required
Additional authorization is required for payouts created under these conditions:
- API payouts: Created via API with
requireAuthparameter set totrue. - Dashboard payouts: Created directly in the Localpayment Dashboard.
Authorization Methods
The method for authorizing payouts depends on how they were originally created:
Dashboard-Created Payouts
For payouts created in the Dashboard, a second user with authorization permissions must authorize.
API-Created Payouts
For payouts created via API, use the Authorize Payout endpoint to programmatically approve transactions.
Prerequisites
Before authorizing payouts, ensure you have:
- An initialized payout transaction with
PendingAuthstatus - Valid API credentials with authorization permissions
- The transaction identifier (
internalIdorexternalId) or date range for bulk authorization
Authorizing Payouts via API
Endpoint
POST https://api.stage.localpayment.com/api/payout/authorizeAuthentication
Include your access token in the request headers:
Authorization: Bearer <your_access_token>Key Request Parameters
You can authorize payouts using one of three methods:
| Parameter | Type | Description | Required |
|---|---|---|---|
internalId | string | LocalPayment's unique transaction identifier | ✅ (Option 1) |
externalId | string | Your system's unique transaction identifier | ✅ (Option 2) |
dateFrom | string | Start date for bulk authorization (YYYY-MM-DD) | ✅ (Option 3) |
dateTo | string | End date for bulk authorization (YYYY-MM-DD) | ✅ (Option 3) |
Choose one authorization method: Use either a specific transaction ID (
internalIdorexternalId) for single transactions, or date range (dateFromanddateTo) for bulk authorization.
Example Requests
curl --request POST \
--url https://api.stage.localpayment.com/api/payout/authorize \
--header 'Authorization: Bearer <your_access_token>' \
--header 'Content-Type: application/json' \
--data '{
"externalId": "1939b376-2aed-4c7a-bc2b-1157702f00b0"
}'Response Handling
Success Response
When authorization is successful, you'll receive:
{
"status": 200,
"message": "The request will be processed."
}Key Response Fields
| Field | Type | Description |
|---|---|---|
status | integer | HTTP status code (200 for success) |
message | string | Confirmation message indicating the request is being processed |
Error Responses
Validation Errors
{
"errors": {
"externalId": [
"The externalId field is required."
]
},
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.1",
"title": "One or more validation errors occurred.",
"status": 400,
"traceId": "00-6af59d173e66ad4eb215987cd15d57af-bea3981476c0f347-00"
}Best Practices
Security Tips
- Always validate transaction details before authorization
- Use HTTPS for all API requests
- Store access tokens securely
- Implement proper error handling and logging
Recommended Workflow
- Create Payout: Generate payout with
requireAuth=true - Verify Status: Confirm transaction status is
PendingAuth - Review Details: Validate transaction information
- Authorize: Call the authorization endpoint
- Handle Response: Process success/error responses appropriately
- Monitor: Track transaction status changes via webhooks
Next Steps
Webhook Integration
Set up real-time notifications for authorization status changes
Transaction Monitoring
Learn how to track transaction status and lifecycle
Reporting & Analytics
Access detailed reports and reconciliation tools
API Reference
Complete API endpoint documentation and examples
Support & Resources
Need assistance with your integration?
- Technical Support: Contact our support team for integration help
- API Documentation: Complete endpoint reference and guides
Pro Tip: Test your authorization workflow in our sandbox environment before implementing in production. This ensures your integration handles all scenarios correctly.
Updated 5 days ago
