Payabli
Embedded payments with merchant risk and payment operations
Payabli combines Pay In acceptance, Pay Out payables, and Pay Ops merchant operations. Public documentation establishes merchant underwriting, payment velocity limits, funding holds, disputes, bank-change review, and reporting. Amigo Insights answers data questions without taking account actions. Separate vendor enrichment can update records and use optional AI outreach. Payment processing, merchant acceptance, and the bank-connected virtual-card credit program have distinct scopes. Public evidence does not establish a standalone AML or sanctions platform.
Our assessment
A documented embedded-payments and merchant-operations platform with scoped risk controls. Evaluate merchant acceptance, bank-connected credit, settlement intervention, and AI permissions separately. Treat AML monitoring, screening-list coverage, reserve management, and direct regulatory filing as unconfirmed.
Best fit and limitations
Fits software platforms that want to embed payment acceptance and vendor payouts with merchant operations. The strongest public evidence concerns the integrated payment lifecycle. Teams buying standalone fraud scores, independent KYC, or a full financial-crime suite need a separate scope review.
- Merchant onboarding includes business and owner verification. Public evidence does not establish a separately available full IDV/KYB service, biometric checks, or every underlying data provider.
- Payabli controls the documented release of risk-held batches. No configurable rolling-reserve calculation or reserve-release API was verified.
- Amigo Insights is read-only. Vendor enrichment writes and beta outreach have narrower authority than the specialist agents advertised as Coming Soon.
- Product pages and technical documentation disagree about network-token support. Use the technical tokenization guide and confirm account-specific availability.
- Canada has narrower method coverage: the region guide lists card acceptance and check payouts. Confirm each product and rail for the proposed region.
- Positive Pay depends on the customer's bank and customer-built file delivery. It is supporting payout data, not Payabli's own check-matching engine.
- References to AML compliance or suspicious-activity indicators do not establish a configurable AML monitoring product, list-screening service, or regulatory filing route.
Tools 26
Pay InEmbedded payment acceptance+
- Accept card, ACH, and supported wallet payments through APIs, components, hosted pages, or the Portal
- Support invoices, payment links, recurring billing, and in-person payment flows; method and region coverage varies
Pay OutVendor payments and managed payables+
- Create payables experiences with vendor records, bills, payment choices, and exception handling
- Use managed service or partner-operated payout flows; confirm each rail and country before integration
Merchant boardingApplication intake and processing activation+
- Collect merchant applications with configured templates, hosted links, or an API integration
- Follow underwriting and activation events before enabling the merchant to process payments
Business and beneficial-owner checksVerification within merchant underwriting+
- Collect business legal and tax details plus owner identity data for Payabli's verification process
- Request supporting documents when digital checks cannot verify the supplied information
- Confirm providers and check coverage; collection fields do not establish biometric checks or complete ownership discovery
Merchant acceptance statusUnderwriting progress and exceptions+
- Expose submitted, underwriting, held, declined, boarding, and activation progress
- Identify missing data, document requests, service-provider review, and configuration steps
- Treat payment-processing acceptance separately from eligibility for a credit product
Transaction velocity controlsPayment fraud limits+
- Limit transactions and declines by card, IP address, payor, and paypoint over defined periods
- Request paypoint-specific settings from Payabli; request-rate limits are a separate control
Fraud Alert webhookPayment-attempt risk notification+
- Report a potentially fraudulent attempt with IP, customer identifiers, event time, and decline context
- Use the event as supporting evidence; its schema does not provide a calibrated fraud score or device fingerprint
Intelligent RiskMerchant portfolio and transaction risk+
- The product page describes ongoing transaction analysis, model-based risk scores, and anomaly flags
- Pay Ops also describes heuristic rules and connected risk vendors; exact model outputs and configuration require confirmation
Risk holds and funding reviewPayabli-operated settlement intervention+
- Place batch funding on hold when risk systems flag suspicious activity
- Payabli reviews and releases held batches; the guide explicitly excludes self-service release
- Read batch and transfer statuses separately to track the movement of funds
Custom batch timesSettlement cutoff configuration+
- Choose an hourly batch cutoff with Payabli's help
- Account for cutoff-dependent funding timing and the transition batch when changing schedules
Fund routing and split fundingDirect accepted funds to designated accounts+
- Route a transaction to a selected merchant account or split funds among configured accounts and paypoints
- Keep fund allocation separate from reserve calculation and release authority
Dispute operationsChargeback evidence and response+
- Submit evidence, accept liability, and record notes with the required Portal role
- Payabli's chargeback team forwards the response to the processor; the operator must meet the reply deadline
- This workflow is not regulatory suspicious-activity reporting
Bank account change casesVerified settlement-account changes+
- Verify a proposed bank account and track the request through a defined case lifecycle
- Platform Partners submit and track; Enterprise Partners can assign, escalate, approve, or deny review cases
- Enablement is required; this specific workflow does not establish a general AML case platform
Reporting APIsPayment and portfolio records+
- Query transactions, payouts, batches, transfers, disputes, and entities with supported filters
- Retrieve aggregate statistics or export records for reconciliation and operational review
Notifications and scheduled reportsEvents for downstream operations+
- Deliver payment, funding, onboarding, and dispute events by webhook or supported message channels
- Schedule reports and retry failed delivery; event receipt does not grant authority to change the underlying payment
Roles and organization scopeOperator access control+
- Assign permissions at organization or paypoint scope and use the documented role hierarchy
- Configure custom roles with Payabli; a managed entity hierarchy is not a fraud-link analysis graph
Amigo InsightsConversational payment analytics+
- Answer questions from permitted organization data and public product knowledge
- Return figures, charts, and tables for payment, dispute, funding, and boarding analysis
Amigo access and action limitsRead-only AI permissions+
- Require organization enablement and amigo_read permission; paypoint-scoped access is not supported
- Exclude payment credentials, tax IDs, secrets, and personal contact data from responses
- Amigo Insights cannot approve boarding, issue refunds, or change configuration
AI vendor enrichmentPayment-method and contact research+
- Use invoice extraction, web research, or existing vendor-network records to fill payment-acceptance details
- Choose automatic empty-field updates or a review-only response with applyEnrichmentData
- Enable the feature with Payabli; payout readiness is not an identity or sanctions verdict
AI vendor outreach — betaOpt-in payment-preference calls+
- Schedule a vendor call directly or after enrichment cannot find enough payment information
- Inspect call state and available transcripts; configure retry and fallback behavior
- Outreach requires separate enablement and pricing; collecting a preference does not execute a payout
Amigo Risk, Chargebacks, and Onboarding roadmapAnnounced specialist agents+
- The Amigo page describes planned risk findings, chargeback drafts, and onboarding assistance
- These three agents are labeled Coming Soon; their action authority and current account availability remain unconfirmed
Positive Pay dataBank-operated check fraud prevention+
- Supply issued-check details for a bank's Positive Pay process
- The customer builds and sends the bank file and handles discrepancies; Payabli does not supply file delivery or the bank's matching decision
Payables funding and AP creditGood-funds and qualified credit programs+
- Managed payables use collected funds; eligible on-demand programs can use a bank-connected credit model
- Credit qualification is documented for virtual-card payouts only, with separate underwriting and approval
- No general lending-policy builder or credit-limit decision API was verified
Stored payment methodsTokenization and fraud-related token removal+
- Use merchant tokens or enabled universal tokens across compatible paypoints on the same processor
- Remove saved methods after specified lost, stolen, or fraudulent-card declines
- Technical documentation says network tokens are not currently supported, despite the Pay In product-page claim
Merchant transaction thresholdsAmount and volume controls+
- Use underwriting information to set typical transaction limits and decline amounts above the threshold
- Request planned increases through Payabli Support; a processing limit is not a merchant reserve
Documentation MCPAI integration guidance+
- Search Payabli documentation and SDK references from an AI development tool
- The published tools retrieve guidance; they do not establish an authenticated payment-action MCP service
AI capabilities
Read-only Insights, scoped enrichment actions, and separate agent roadmap
Amigo Insights supplies analytics. Vendor enrichment has documented automatic and review modes; AI outreach is opt-in beta. The product site also describes risk models. Amigo Risk, Chargebacks, and Onboarding remain labeled Coming Soon. These are different evidence levels and operating permissions.
What to validate
Apply organization scope and amigo_read permissions to Insights. Use enrichment review mode when a person must approve changes. Confirm outreach settings and beta access. Do not infer payment, refund, underwriting, or reserve authority from an agent label.
Implementation
Integration checklist
- Map organizations, paypoints, and entry identifiers before connecting payment and reporting calls. Check role scope for each operation.
- Confirm templates, funding settings, bank-change access, and enrichment enablement with Payabli before implementation.
- Use OAuth2 for new integrations and endpoints that require it. Handle business response fields as well as HTTP status.
- Use transaction identifiers to reconcile webhooks with requests. The general POST idempotency window is two minutes; resolve uncertain outcomes before a later retry.
- Track payment, batch, transfer, and review states separately. An approved transaction does not establish deposited funds or a released hold.
- Test enrichment in review mode and handle partial results. Keep permission to update vendor records separate from permission to send money.
Commercial scope
Confirm platform fees, processing and payout costs, bank-connected credit terms, enabled risk features, and support duties in the contract. Public documentation requires Payabli setup for several controls and separate discussion of beta outreach pricing; it does not establish a complete rate card or account entitlement.
Questions for the demo
- Which merchant-verification providers and checks apply to each region, entity type, and owner?
- Which risk scores, rule controls, model versions, and explanations can a partner inspect or change?
- Who can hold or release funds, change limits, and approve bank-account cases under this partner agreement?
- Are merchant reserves supported, and where are calculation, withholding, release, and audit controls documented?
- Which Amigo products are enabled today, and which remain beta or Coming Soon?
- What approval, pricing, retention, and escalation controls apply to enrichment and AI outreach?
- Which bank provides the virtual-card credit program, and who sets eligibility, exposure limits, and repayment terms?
Engineering
- Inputs
- POST /api/v2/Token/serverside: clientId, clientSecret, and optional permission IDs · POST /api/v2/MoneyIn/getpaid: paymentDetails, paymentMethod, paypoint entryPoint, and relevant customer context · POST /api/MoneyOut/authorize followed by GET /api/MoneyOut/capture/{referenceId}, or POST /api/MoneyOut/payout for combined execution · POST /api/Boarding/app: product-specific merchant application and requested payment services · Business legal identity, tax identifier, address, business description, website, and beneficial-owner identity/contact details · POST /api/ChargeBacks/response/{Id}: dispute record ID, notes, submitter contact fields, and optional attachments · Boarding application estimates for processing volume and ticket size · POST /api/v2/cases/bank-account/{paypointId}/validate and POST /api/v2/cases/bank-account/{paypointId}: account details, function, and requested services · Natural-language analytics questions within the user's organization scope · POST /api/Vendor/enrich/{entry}: vendorId, scope, and invoiceFile for invoice_scan; applyEnrichmentData selects apply or review mode · Sensitive payment details collected through the configured tokenization flow
- Outputs
- Bearer access_token, token_type, and expires_in · Unified code, reason, explanation, action, and data.paymentTransId · Transaction details can include riskFlagged, riskFlaggedOn, and riskActionCode · Payout referenceId and capture result; risk review can return HTTP 202/code 9051, while a blocking policy returns HTTP 422/code 9005 · Application operation response with isSuccess, responseCode, responseData, and roomId · Boarding status and substatus, including Underwriting 3, Manual Review 6, Approved 7, Boarding 10, Activated 99, and Live 100 · Event-specific notifications for payments, boarding, disputes, fraud, holds/releases, transfers, and payouts · FraudAlert event with merchant, IP, customer identifiers, description, timestamp, and card-decline reason fields · isSuccess and responseText; responseData carries the dispute identifier on success · Separate BatchStatus and TransferStatus; Held batch status is -5 · A transaction above the merchant's defined amount limit is declined · Validation: isValid, blockingConditions, warnings, validationErrors; creation: case uuid and Submitted state · Verification result codes in metadata.verification and case states through Completed or Denied · Permitted business analytics and answers · Enrichment status, extracted data, and stagesTriggered; applied values update the vendor record · storedMethodId for a saved payment method
- Webhooks
- Notifications enter the queue within five minutes of the trigger. Delivery uses HTTP POST. Failed requests receive two retries at five-minute intervals, then support manual retry through notification logs. Custom authorization headers and environment-specific source IPs are documented. Return HTTP 200 after accepting a webhook. The payload reference says any other response causes retries. Configure the fraudalert notification for potentially fraudulent payment attempts.
- Decision timing
- Write requests time out after 30 seconds; reads after 90 seconds. These limits are not processing latency guarantees. The sale endpoint authorizes and captures in one call. Read the unified result code and later funding state separately. autoCapture on authorization runs asynchronously; confirm the approvedcaptured webhook. The combined payout endpoint returns the capture outcome synchronously. Approval queues an application for boarding. Activated means configuration is complete; Live means a payment has processed. No underwriting completion SLA was verified. Payabli reviews and releases batches held for risk. Review duration depends on the case. Bank verification and account switching run asynchronously. Poll case status; do not assume submission completed the switch.
- Deployment
- Hosted API · Embedded components · Hosted payment pages
- Dependencies
- Backend-only credentials with permissions and separate sandbox/production scope · Payabli-provisioned sandbox access and production onboarding · Paypoint entrypoint and endpoint-appropriate authentication · Sandbox account; Payabli staff for selected underwriting, funding, and ACH-return scenarios · Correct paypoint payment-method and currency configuration; real-time achValidation is an add-on · Organization access and application credentials; the endpoint specifies an application API token · Additional supporting documents when digital verification is insufficient · Payabli risk review for held-batch release · Payabli Support for threshold increases or advance approval of unusual volume · Payabli-enabled Case Management access and OAuth Bearer authentication · Enterprise Partner access for assignment, escalation, approval, and denial; Platform Partners submit and track while Payabli decides · Organization enablement and amigo_read permission; paypoint-scoped access is not supported · Payabli-enabled enrichment, vendor permissions, and an active vendor · Separate opt-in beta access and provisioned calling number for AI outreach · Merchant domicile, domestic bank, and payment-rail eligibility · Merchant-token scope by default; universal tokens require enabled merchants on the same processor
Verified details 57
- Inputs
POST /api/v2/Token/serverside: clientId, clientSecret, and optional permission IDs
Source Checked 2026-09-18 - Outputs
Bearer access_token, token_type, and expires_in
Source Checked 2026-09-18 - Dependency
Backend-only credentials with permissions and separate sandbox/production scope
Source Checked 2026-09-18 - Decision timing
Write requests time out after 30 seconds; reads after 90 seconds. These limits are not processing latency guarantees.
Source Checked 2026-09-18 - Deployment
Hosted API
Source Checked 2026-09-18 - Dependency
Payabli-provisioned sandbox access and production onboarding
Source Checked 2026-09-18 - Dependency
Paypoint entrypoint and endpoint-appropriate authentication
Source Checked 2026-09-18 - Dependency
Sandbox account; Payabli staff for selected underwriting, funding, and ACH-return scenarios
Source Checked 2026-09-18 - Inputs
POST /api/v2/MoneyIn/getpaid: paymentDetails, paymentMethod, paypoint entryPoint, and relevant customer context
Source Checked 2026-09-18 - Outputs
Unified code, reason, explanation, action, and data.paymentTransId
Source Checked 2026-09-18 - Outputs
Transaction details can include riskFlagged, riskFlaggedOn, and riskActionCode
Source Checked 2026-09-18 - Decision timing
The sale endpoint authorizes and captures in one call. Read the unified result code and later funding state separately.
Source Checked 2026-09-18 - Dependency
Correct paypoint payment-method and currency configuration; real-time achValidation is an add-on
Source Checked 2026-09-18 - Inputs
POST /api/MoneyOut/authorize followed by GET /api/MoneyOut/capture/{referenceId}, or POST /api/MoneyOut/payout for combined execution
Source Checked 2026-09-18 - Outputs
Payout referenceId and capture result; risk review can return HTTP 202/code 9051, while a blocking policy returns HTTP 422/code 9005
Source Checked 2026-09-18 - Decision timing
autoCapture on authorization runs asynchronously; confirm the approvedcaptured webhook. The combined payout endpoint returns the capture outcome synchronously.
Source Checked 2026-09-18 - Inputs
POST /api/Boarding/app: product-specific merchant application and requested payment services
Source Checked 2026-09-18 - Outputs
Application operation response with isSuccess, responseCode, responseData, and roomId
Source Checked 2026-09-18 - Dependency
Organization access and application credentials; the endpoint specifies an application API token
Source Checked 2026-09-18 - Inputs
Business legal identity, tax identifier, address, business description, website, and beneficial-owner identity/contact details
Source Checked 2026-09-18 - Dependency
Additional supporting documents when digital verification is insufficient
Source Checked 2026-09-18 - Outputs
Boarding status and substatus, including Underwriting 3, Manual Review 6, Approved 7, Boarding 10, Activated 99, and Live 100
Source Checked 2026-09-18 - Decision timing
Approval queues an application for boarding. Activated means configuration is complete; Live means a payment has processed. No underwriting completion SLA was verified.
Source Checked 2026-09-18 - Outputs
Event-specific notifications for payments, boarding, disputes, fraud, holds/releases, transfers, and payouts
Source Checked 2026-09-18 - Webhooks
Notifications enter the queue within five minutes of the trigger. Delivery uses HTTP POST. Failed requests receive two retries at five-minute intervals, then support manual retry through notification logs. Custom authorization headers and environment-specific source IPs are documented.
Source Checked 2026-09-18 - Webhooks
Return HTTP 200 after accepting a webhook. The payload reference says any other response causes retries.
Source Checked 2026-09-18 - Outputs
FraudAlert event with merchant, IP, customer identifiers, description, timestamp, and card-decline reason fields
Source Checked 2026-09-18 - Webhooks
Configure the fraudalert notification for potentially fraudulent payment attempts.
Source Checked 2026-09-18 - Inputs
POST /api/ChargeBacks/response/{Id}: dispute record ID, notes, submitter contact fields, and optional attachments
Source Checked 2026-09-18 - Outputs
isSuccess and responseText; responseData carries the dispute identifier on success
Source Checked 2026-09-18 - Outputs
Separate BatchStatus and TransferStatus; Held batch status is -5
Source Checked 2026-09-18 - Decision timing
Payabli reviews and releases batches held for risk. Review duration depends on the case.
Source Checked 2026-09-18 - Dependency
Payabli risk review for held-batch release
Source Checked 2026-09-18 - Inputs
Boarding application estimates for processing volume and ticket size
Source Checked 2026-09-18 - Outputs
A transaction above the merchant's defined amount limit is declined
Source Checked 2026-09-18 - Dependency
Payabli Support for threshold increases or advance approval of unusual volume
Source Checked 2026-09-18 - Inputs
POST /api/v2/cases/bank-account/{paypointId}/validate and POST /api/v2/cases/bank-account/{paypointId}: account details, function, and requested services
Source Checked 2026-09-18 - Outputs
Validation: isValid, blockingConditions, warnings, validationErrors; creation: case uuid and Submitted state
Source Checked 2026-09-18 - Dependency
Payabli-enabled Case Management access and OAuth Bearer authentication
Source Checked 2026-09-18 - Outputs
Verification result codes in metadata.verification and case states through Completed or Denied
Source Checked 2026-09-18 - Decision timing
Bank verification and account switching run asynchronously. Poll case status; do not assume submission completed the switch.
Source Checked 2026-09-18 - Dependency
Enterprise Partner access for assignment, escalation, approval, and denial; Platform Partners submit and track while Payabli decides
Source Checked 2026-09-18 - Inputs
Natural-language analytics questions within the user's organization scope
Source Checked 2026-09-18 - Outputs
Permitted business analytics and answers
Source Checked 2026-09-18 - Dependency
Organization enablement and amigo_read permission; paypoint-scoped access is not supported
Source Checked 2026-09-18 - Inputs
POST /api/Vendor/enrich/{entry}: vendorId, scope, and invoiceFile for invoice_scan; applyEnrichmentData selects apply or review mode
Source Checked 2026-09-18 - Outputs
Enrichment status, extracted data, and stagesTriggered; applied values update the vendor record
Source Checked 2026-09-18 - Dependency
Payabli-enabled enrichment, vendor permissions, and an active vendor
Source Checked 2026-09-18 - Dependency
Separate opt-in beta access and provisioned calling number for AI outreach
Source Checked 2026-09-18 - Country scope
United States
Source Checked 2026-09-18 - Country scope
Canada
Source Checked 2026-09-18 - Dependency
Merchant domicile, domestic bank, and payment-rail eligibility
Source Checked 2026-09-18 - Inputs
Sensitive payment details collected through the configured tokenization flow
Source Checked 2026-09-18 - Outputs
storedMethodId for a saved payment method
Source Checked 2026-09-18 - Deployment
Embedded components
Source Checked 2026-09-18 - Deployment
Hosted payment pages
Source Checked 2026-09-18 - Dependency
Merchant-token scope by default; universal tokens require enabled merchants on the same processor
Source Checked 2026-09-18
Vendor example
Published vendor example. Confirm the current version and required credentials.
{
"errorType": "InvalidCredentials",
"errorMessage": "Invalid client credentials."
}Integration limits
- Published vendor payload example, linked to its source. It is not a complete integration or a tested production request.
- Empty country, deployment, or provider lists mean not verified in this review. A documented country refers to the specific product noted in its source, not universal platform coverage.
- Read expires_in rather than assuming a fixed token lifetime. Existing requestToken integrations coexist with OAuth; some endpoints require OAuth.
- Credential rotation or revocation does not invalidate already issued tokens before expiry.
- The vendor example is the documented HTTP 400 authentication error. It is not a fraud decision and was not executed.
- Sandbox uses api-sandbox.payabli.com/api; production uses api.payabli.com/api. Production requests can move money.
- POST idempotencyKey values last two minutes. A repeated key returns 409 rather than a cached success. Reconcile a timed-out payment before another attempt. Webhooks correlate through transId, not the idempotency key.
- Published token request limits are 200/minute, 3,000/15 minutes, and 10,000/hour. Separate paypoint controls limit transaction and decline velocity by card, IP, payor, and paypoint; changes require Payabli.
- Sandbox supports test payments and chargeback CSV import. ACH returns and held/released or exception funding tests require a solutions engineer.
- Sandbox boarding does not perform actual underwriting or automatically create paypoints. Staff must advance those scenarios. A successful sandbox request does not prove production underwriting or funding behavior.
- This is a payment execution endpoint. Its risk fields do not establish a standalone predictive score API. The action response field supplies recommended next steps; it is not evidence that a separate action ran.
- The 202 risk-review result has isSuccess=false but is a held capture, not a terminal rejection. Support handles risk-limit issues.
- If combined payout capture fails, the authorization remains. Reuse its referenceId for capture; do not create a duplicate payout. Pay Out has no refunds, and processed payouts cannot be reversed through cancellation.
- Creating an application does not establish approval or payment activation. Follow its boarding status. The generated reference lists both auth schemes; confirm the accepted credential and scope for the selected boarding flow.
- These are inputs to merchant underwriting. This reference does not establish a separately callable KYC, sanctions-screening, or identity-scoring product. No underlying identity or sanctions data provider was verified here.
- Manual-review substatuses distinguish pending review, documents, action, and missing data. Preserve these states rather than treating application creation as approval.
- Queue timing is not an end-to-end delivery SLA. A signed-body verification scheme, delivery-order guarantee, and acknowledgment timeout were not verified. Implement duplicate handling and reconciliation.
- The general notification guide says a success status is sufficient, while this reference explicitly requires 200. Use 200 to satisfy both descriptions.
- This event supplies an alert payload. It does not expose a numeric risk score, model explanation, or general-purpose risk-policy API.
- This submits a response to a chargeback or ACH return. Submission success does not mean the dispute was won. Attachment entries support file content or a URL; the documented upload limit is 30 MB.
- The guide explicitly excludes self-service release of held batches. A held batch or release webhook does not establish a partner-controlled reserve or release API. Reserve creation, percentage changes, and release schedules were not verified in the reviewed public API.
- This supports enforced merchant limits. A public partner API for editing those risk limits was not verified.
- Poll GET /api/v2/cases/{uuid} for progress. Raw account and routing numbers are write-only; case responses carry bankToken. A scheduling timestamp can delay the approved switch.
- The documented case workflow concerns bank account changes. It does not prove a general-purpose fraud case engine or autonomous underwriting decision API.
- Amigo Insights cannot approve boarding, refund payments, or change settings. Its data-access layer excludes payment credentials, personal contact data, tax IDs, and secrets. These documented limits do not prevent separate, explicitly enabled vendor-enrichment workflows.
- The documented automation researches payment acceptance and contact details. It does not establish autonomous risk approvals. Review mode returns data for confirmation; creation-time scans fill empty fields and retain supplied values.
- POST /api/Vendor/enrich/schedule_call/{entry} schedules an AI vendor call. Outreach and call-status endpoints are beta. A failed enrichment scan does not block vendor or bill creation.
- Pay In supports card and ACH for U.S. states/DC and card only for Canadian merchants; U.S. territories are excluded. Pay Out lists U.S. vCard/ACH/check and Canada check only. Territory Pay Out requires a U.S.-based bank account. These are rail-specific limits, not global platform coverage.
- The technical guide says network tokens are not currently supported. Confirm this limitation with Payabli before relying on broader product claims. Payment tokens are distinct from API authentication tokens.
Sources 30
Source review dates are shown above. Product claims come from public sources. Fit, limits, and evaluation questions are our analysis. This is not a hands-on performance test. Methodology · Changelog