> This is Payabli documentation. For a complete page index, fetch https://docs.payabli.com/llms.txt — append .md to any page URL for lightweight markdown. For section-level indexes, query parameters, and other AI-optimized access methods, see https://docs.payabli.com/ai-agents.md
# IVR payments overview
> How IVR payments work, payment types supported, and compliance considerations
Interactive Voice Response (IVR) payments let your merchants collect payments over the phone, any time of day, without a live agent. Callers provide payment details by pressing keys on their phone keypad, a method known as dual-tone multi-frequency (DTMF) signaling. The IVR system then submits the transaction directly to Payabli for real-time processing.
IVR payments are a good fit for verticals where phone-based payment is common or preferred, including property management, utilities, field services, storage, and healthcare billing.
IVR payments are available to all active Payabli paypoints with card or ACH processing enabled.
## How IVR payments work
Payabli's IVR integration uses [SharpenCX](https://www.sharpencx.com/) (formerly Plum Voice), a PCI-compliant IVR platform. Your call tree lives in SharpenCX and orchestrates the caller experience: playing prompts, collecting input, and making API calls to your platform and to Payabli.
Payabli doesn't host or manage the call tree itself. Call tree logic varies by use case, but a typical IVR payment flow looks like this:
1. The caller dials your PCI-compliant phone number provisioned in SharpenCX.
2. The call tree captures the caller's phone number automatically and performs an account lookup against your platform's API. If there's no match, it prompts the caller to say or enter the phone number on file and retries the lookup.
3. Your platform returns account details. For org or sub-org level call trees, this response should include the Payabli paypoint `entryPoint` so the call tree knows where to submit the payment.
4. The caller is identified and asked how much to pay: the full balance or a custom amount.
5. The caller chooses a payment method. If saved payment methods are available, the call tree offers those as an option before prompting for new details.
6. The caller enters payment details via keypad.
7. The call tree submits a `POST` request to the Payabli [`/v2/MoneyIn/getpaid`](/developers/api-reference/moneyinV2/make-a-transaction) endpoint with `"source": "ivr"` in the request body.
8. Payabli processes the transaction and returns the status and a unique transaction identifier in the response.
9. The call tree reads the result back to the caller via text-to-speech (TTS): confirming success with a confirmation number, or prompting a retry on failure.
10. \[Recommended] Send a confirmation email or SMS to the caller. This is required for ACH transactions under Nacha rules. See [Nacha compliance for ACH IVR](#nacha-compliance-for-ach-ivr).
#### Diagram: Typical IVR payment call flow
This sequence diagram shows how a typical IVR payment moves between four actors: the caller, the SharpenCX IVR call tree, the partner platform's API, and Payabli.
1. The caller dials the PCI-compliant phone number provisioned in SharpenCX.
2. The IVR call tree performs an account lookup against the partner platform using the autodetected caller ID.
3. The partner platform returns account details along with the paypoint `entryPoint`.
4. The IVR call tree prompts the caller for an amount and a payment method.
5. The caller enters payment details via the DTMF keypad.
6. The IVR call tree submits a POST request to `/v2/MoneyIn/getpaid` with `"source": "ivr"`.
7. Payabli returns a response containing the unified response `code` and `paymentTransId`.
8. The IVR call tree reads a text-to-speech confirmation or retry prompt back to the caller.
9. The partner platform sends an email or SMS confirmation to the caller. This step is recommended for card payments and required for ACH payments under Nacha rules.
## Ways to build your IVR integration
You have two paths to get an IVR call tree in production.
Work with Payabli to design, build, and maintain your IVR call tree in SharpenCX. Reach out to your Partner Success Manager to schedule a working session.
Create your own SharpenCX account, provision a PCI-compliant number, and build the call flow yourself using Plum Fuse (no-code), Plum VoiceXML, or the Plum Dev APIs.
If you're building the call tree yourself, SharpenCX offers three approaches:
* [**Plum Fuse**](https://docs.plumvoice.com/fuse): a no-code, drag-and-drop call tree designer. The fastest way to get started.
* [**Plum VoiceXML**](https://docs.plumvoice.com/dev/developer-reference/tutorial): build call flows in VoiceXML for full programmatic control.
* [**Plum Dev APIs**](https://docs.plumvoice.com/dev/plum-dev-apis/dev-outbound-apis): build and manage call trees and trigger outbound calls programmatically.
## Supported payment types
Payment details are collected via DTMF keypad input. SharpenCX does support voice input, but the best practice for payment data collection is to use DTMF. It's more reliable for sensitive fields like card numbers, and the keypad press serves as the payor's authorization to process the payment.
Callers can pay by entering new payment details or by selecting a saved payment method already on file. If your platform returns saved payment method details (Payabli token, card brand and last 4 digits, or bank account last 4) during the account lookup, your call tree can offer those options to the caller instead of prompting for manual entry.
### Card payments
Card payments are the most common IVR use case. Card processing provides immediate approval or decline, which means callers get instant confirmation that the payment went through, and merchants don't have to worry about returns days later.
IVR card transactions are processed as card-not-present. Payabli supports Visa, Mastercard, American Express, Discover, JCB, and Diners Club for IVR.
The call tree must collect the following from the caller:
| Data collected | Field | Notes |
| ----------------- | ------------ | ------------------------------------------------------------------------------------- |
| Card number (PAN) | `cardnumber` | 15 to 16 digits. |
| Expiration date | `cardexp` | MMYY or MM/YY format. |
| Security code | `cardcvv` | 3 to 4 digits depending on card brand. Helps improve card-not-present approval rates. |
| Billing ZIP code | `cardzip` | 5 digits. Facilitates AVS check and can lower interchange cost. |
Populate `cardHolder` from your account lookup response.
### ACH payments
ACH usage in IVR is less common than card because ACH transactions don't offer instant finality: returns can occur days after the original transaction. ACH IVR is still fully supported and can be a good fit for merchants whose customers prefer bank account payments.
Payabli supports personal (TEL) and business (CCD) one-time ACH payments via IVR, plus saved ACH payment methods that inherit the SEC code from the token.
The call tree must collect the following from the caller:
| Data collected | Field | Notes |
| ------------------- | ---------------- | -------------------------------------------------- |
| Account holder type | `achHolderType` | `personal` or `business`. Determines the SEC code. |
| Account type | `achAccountType` | `Checking` or `Savings`. |
| Routing number | `achRouting` | 9-digit ABA routing number. |
| Account number | `achAccount` | 4 to 17 digits. |
Populate `achHolder` from your account lookup response.
Set the `achCode` (SEC code) based on account holder type: `TEL` for personal accounts and `CCD` for business accounts on one-time payments. When a caller uses a saved ACH payment method, you don't need to send `achCode`. Payabli retrieves it from the saved token record.
#### Nacha compliance for ACH IVR
ACH IVR transactions have specific Nacha authorization requirements that you need to build into your call tree. Payabli recommends coordinating with your Partner Success Manager to schedule a discovery call before implementing ACH IVR. This will ensure that your call tree design is compliant and you're protected in the event of a dispute.
To accept ACH via IVR, you must take care of these compliance requirements:
Before submitting the payment, the call tree must play an explicit authorization prompt to the caller. For example:
*"Press 1 to authorize \[Business Name] to debit $\[amount] from your \[checking/savings] account ending in \[last 4 digits] on \[date]. Press 2 to cancel."*
After a successful ACH payment, send an email or SMS confirmation to the caller containing all Nacha-required elements. For example:
*"You authorized \[Business Name] to debit $\[amount] from the account ending in \[xxxx] on \[date]. To cancel or dispute this transaction, call \[partner customer support number]."*
Your platform must save the IVR call log as evidence that the caller heard all prompts and provided confirmation. The call log, together with the email or SMS confirmation, serves as your primary defense if an ACH return or dispute arises.
### Saved payment methods
If your platform stores Payabli tokens for returning payors, your call tree can offer those saved methods during the call instead of asking the caller to re-enter details.
For this to work, your account lookup API needs to return the Payabli token ID along with display details so the caller can identify the method:
* **Saved card:** Payabli token ID, card brand, and last 4 digits.
* **Saved ACH:** Payabli token ID and last 4 digits of the account number.
The call tree presents the saved methods, the caller selects one, and the call tree submits the Payabli token ID in `storedMethodId` on the `/v2/MoneyIn/getpaid` request. See the [saved payment method example](/guides/pay-in-developer-ivr-payments#example-saved-payment-method) in the integration guide for the request shape.
## PCI compliance and scope
SharpenCX is a PCI Level 1 certified platform. It's also SOC 2, ISO 27001, GDPR, and HIPAA compliant. SharpenCX provides PCI DSS-compliant phone number provisioning, keypad/DTMF tone capture, voice input, and PCI-compliant storage and transmission of sensitive data.
Sensitive cardholder data entered by the caller is handled entirely within the SharpenCX PCI environment and passed directly to Payabli's API. It doesn't pass through your platform servers, which keeps your PCI scope minimal. Your platform only needs to handle the non-sensitive parts of the call flow, like account lookup queries, not raw payment credentials.
## Identifying IVR transactions
All IVR-originated transactions must include `"source": "ivr"` in the `/v2/MoneyIn/getpaid` request body. This flag makes sure IVR transactions are correctly classified in reporting and dispute handling.
Unlike some payment platforms, Payabli doesn't require a permission token or enablement step for IVR. You only need to collect the right payment details in your call tree and submit them to Payabli with `"source": "ivr"`.
## Get started
Ready to build? See the [IVR integration guide](/guides/pay-in-developer-ivr-payments) for prerequisites and a step-by-step walkthrough of provisioning a phone number, building and testing a call tree, and deploying to production.
## Related resources
See these related resources to help you get the most out of Payabli.
* **[Accept IVR payments (API)](/guides/pay-in-developer-ivr-payments)** - Ready to build? Follow the integration guide
* **[Pay In unified response codes reference](/guides/pay-in-unified-response-codes-reference)** - Complete reference for Payabli's unified Pay In transaction response codes
* **[ACH payments cycle](/guides/pay-in-ach-cycle-overview)** - Learn how ACH transactions work
* **[Make a sale transaction with the API](/guides/pay-in-developer-transactions-create)** - Learn how to authorize and capture a sales transaction in one step using the API