Purpose and Workflow
When your platform receives aPayment Admission Task
, you are expected to process it by:
- Authenticating the request with your customer using your preferred mechanism (e.g., biometric, OTP, PIN)
- Accepting or rejecting the task based on your customer’s response or internal checks
Common Use Case: Pull Payments
In pull payment scenarios—such as when a merchant requests a payment from a customer—the customer’s financial platform receives an Admission Task. Example:
Customer adds items to their cart, enters their Paylias, and the merchant’s partner submits a pull payment. Paylias creates a Payment Admission
and assigns an Admission Task to the customer’s platform. The platform must now authenticate and confirm the request with the customer.
Reason Codes
When rejecting a task, one of the followingstatus_reason
values should be used:
Reason Code | Description |
---|---|
accepted | Customer accepted the request |
invalid_beneficiary_details | Beneficiary info was invalid |
alias_not_provisioned | Alias exists but is not active |
unknown_alias | Alias is unrecognized |
account_closed | Customer account is closed |
duplicate_payment | Detected as a duplicate |
blocked_account | Customer is blocked |
currency_mismatch | Currency not supported |
business_reasons | Rejected due to internal policies |
deceased_account_holder | Account holder is deceased |
insufficient_funds | Not enough balance |
unknown_error | Generic system error |
fraud_detected | Triggered fraud alert |
regulatory_issues | Rejected due to compliance policies |
account_unavailable | Account temporarily inaccessible |
Webhook Integration
To receive tasks in real-time, subscribe to the following webhook events:payment_admission_task:created
payment_admission_task:updated
Respond to an Admission Task
Complete an admission task
Reject an admission task
Response
Fetch a Task by ID
Fetch