Pay In cookbook
Use these recipes to get started with Pay In features and functions. See Pay In overview for more.
New to the API? Start with the authentication guide on the cookbooks home.
Recipe: Run your first sale transaction
/// OverviewThis end-to-end workflow walks through how to run a card sale transaction using the API. The getpaid endpoint authorizes and captures the transaction in one step, so it’s immediately captured for settlement. This recipe uses the v2 transaction API, which all new integrations should use.
/// Prerequisites
Before you start, make sure you have the following:
- Your paypoint’s
entryPointvalue - A
customerIdfor the customer making the payment. If you don’t have one, create a customer first. - The customer’s payment details: for a card transaction, this includes the card number, expiration date, CVV, and billing ZIP code
PCI compliance note: This recipe passes raw card data directly through the API for demonstration purposes. In production, use an embedded component to collect card details, or use a stored payment method, which keeps your PCI scope minimal. If you handle raw card data directly, your PCI scope is expanded and you must secure cardholder data and customer IP addresses.
/// Step 1: Run the sale transaction
Send a POST request to /api/v2/MoneyIn/getpaid with the payment method, amount, and customer information. This authorizes and captures the transaction in one step.
A successful response returns code A0000 (Approved) and a paymentTransId in the data object that you can use to look up the transaction later.
See Make a transaction (v2) for the full API reference.
/// Step 2: Check the transaction status
Use the paymentTransId from the previous step to check the transaction’s status and details.
Send a GET request to /api/MoneyIn/details/{paymentTransId}.
Since the getpaid endpoint authorizes and captures in one step, the transStatus is Captured (1). To track settlement progress, watch the settlementStatus field as it moves from Pending (0) through In Transit (1), Transferred (2), and Funded (3). See the Pay In lifecycle for more.
See Get details for a processed transaction for the full API reference.
/// What’s next
Congratulations! You just ran your first sale transaction. Next, learn about the Pay In transaction lifecycle and explore running transactions with other payment methods.
Recipe: Create a customer
/// OverviewCreate a customer record in Payabli to track payers, store payment methods, and manage subscriptions. Customer records require at least one identifier field.
/// Prerequisites
Before you start, make sure you have the following:
- Your paypoint’s
entrypointvalue - At least one customer identifier:
firstnameandlastname,email, or a custom identifier
Check your identifier settings in Settings > Custom Fields in PartnerHub. See custom identifiers for more.
/// Create the customer
Send a POST request to /api/Customer/single/{entry} with the customer’s details. Include identifier fields so Payabli can match against existing records.
The response includes a customerId that you can use with other endpoints to manage the customer and run transactions.
See Add customer for the full API reference.
/// What’s next
Congratulations! You’ve created a customer record. Learn more about managing customers with the API and customer entities in Payabli.
Recipe: Refund a transaction
/// OverviewRefund a settled Pay In transaction to return funds to the customer. You can refund the full amount or a partial amount. This recipe uses the v2 API.
/// Prerequisites
Before you start, make sure you have the following:
- The
referenceIdof a settled transaction (also called thetransId) - The refund amount, if you’re issuing a partial refund
If the transaction hasn’t settled yet, void it instead.
/// Refund the transaction
For a full refund, send a POST request to /api/v2/MoneyIn/refund/{transId}. For a partial refund, append the amount: /api/v2/MoneyIn/refund/{transId}/{amount}. The refund amount excludes any service fee charged on the original transaction.
This example refunds the full transaction amount:
A successful refund returns a code of A0004 with a reason of “Refunded”. The data object contains the full transaction details.
To refund a partial amount, include the amount in the path. This example refunds $100.99:
See Refund a settled transaction (v2) for the full API reference.
/// What’s next
Congratulations! You’ve refunded a Pay In transaction. Learn about choosing between void and refund and the Enhanced Refund Flow.
Recipe: Void a transaction
/// OverviewVoid an unsettled Pay In transaction to cancel it before the batch closes. Voids cancel the full transaction amount — partial voids aren’t supported. This recipe uses the v2 API.
/// Prerequisites
Before you start, make sure you have the following:
- The
referenceIdof an unsettled transaction (also called thetransId)
If the transaction has already settled, refund it instead.
/// Void the transaction
Send a POST request to /api/v2/MoneyIn/void/{transId}.
A successful void returns a code of A0003 with a reason of “Canceled”. The data object contains the full transaction details.
If you try to void a transaction that has already been settled or voided, the API returns a 400 status.
See Void a transaction (v2) for the full API reference.
/// What’s next
Congratulations! You’ve voided a Pay In transaction. Learn about choosing between void and refund and explore other cancellation methods.
Recipe: Charge a saved payment method
/// OverviewCharge a returning customer using a payment method you’ve already tokenized and stored, without collecting their card or bank account details again. This recipe uses the v2 transaction API, which all new integrations should use.
/// Prerequisites
Before you start, make sure you have the following:
- A
storedMethodIdfor the customer’s saved payment method. If you haven’t saved one yet, see Save a payment method. - The
customerIdfor the customer who owns the stored method - Your paypoint’s
entryPointvalue - Know whether the stored method is a
cardorachmethod, so you can set themethodfield correctly
/// Step 1: Run the transaction
Send a POST request to /api/v2/MoneyIn/getpaid with the storedMethodId in the paymentMethod object instead of raw card or bank account details.
Set initiator to payor for customer-initiated transactions, or merchant for merchant-initiated transactions. See CIT and MIT overview for guidance on which to use.
A successful response returns code A0000 (Approved) and a paymentTransId in the data object that you can use to look up the transaction later.
See Make a transaction (v2) for the full API reference.
/// Step 2: Check the transaction status
Use the paymentTransId from the previous step to check the transaction’s status and details.
Send a GET request to /api/MoneyIn/details/{paymentTransId}.
Since the getpaid endpoint authorizes and captures in one step, the transStatus is Captured (1). To track settlement progress, watch the settlementStatus field as it moves from Pending (0) through In Transit (1), Transferred (2), and Funded (3). See Pay In lifecycle for more.
See Get details for a processed transaction for the full API reference.
/// What’s next
Congratulations! You just charged a saved payment method. Next, learn about tokenization and explore other ways to make transactions.
Recipe: Send a payment link
/// OverviewGenerate a payment link from an existing invoice and send it to a customer via email. Payment links direct customers to a hosted payment page where they can pay using your accepted methods.
/// Prerequisites
Before you start, make sure you have the following:
- An
idInvoicefor an invoice created via the API. If you haven’t created one yet, see Manage invoices. - Your paypoint’s
entryPointvalue - The customer’s email address
/// Step 1: Generate the payment link
Create a payment link from your invoice. You can customize the hosted payment page’s branding, accepted payment methods, and layout.
Send a POST request to /api/PaymentLink/{idInvoice}.
The response includes the payment link ID in responseData. You need this ID to send the link in the next step.
See Create payment link from invoice for the full API reference.
/// Step 2: Send the payment link
Send the payment link to the customer via email. You can include additional recipients and attach a PDF invoice.
Send a POST request to /api/PaymentLink/push/{payLinkId}.
A successful response returns the payLinkId and a success message.
See Send payment link for the full API reference.
/// What’s next
Congratulations! You just sent a payment link to your customer. Next, learn about choosing an invoice delivery strategy and explore all the ways to manage payment links.
Recipe: Create and send an invoice
/// OverviewCreate a one-time invoice for a customer and send it via email with an attached PDF. This recipe covers the two-call workflow: create the invoice, then send it.
/// Prerequisites
Before you start, make sure you have the following:
- Your paypoint’s
entryPointvalue - A
customerIdfor an existing customer. If you haven’t created one yet, see Manage customers. - Invoice details: line items, amounts, and a unique invoice number
/// Step 1: Create the invoice
Create the invoice linked to an existing customer. The request includes customer identification, line items, amount, and invoice metadata.
Send a POST request to /api/Invoice/{entry}.
The response includes the invoice ID in responseData. You need this to send the invoice in the next step.
See Add invoice for the full API reference.
/// Step 2: Send the invoice
Email the invoice to the customer. Use attachfile=true to include a PDF copy, and mail2 to specify the recipient email address. If you omit mail2, Payabli sends the invoice to the email address on file for the customer.
Send a GET request to /api/Invoice/send/{idInvoice}.
See Send invoice via email for the full API reference.
/// What’s next
Congratulations! You just created and sent an invoice. Next, explore the full invoice lifecycle in Manage invoices with the API and learn how to choose an invoice delivery strategy.
Recipe: Retrieve batches and transfers
/// OverviewRetrieve a list of batches and transfers for a paypoint to monitor settlement activity. A batch is a group of transactions that are settled together at the end of a processing cycle. A transfer is the actual movement of funds from the batch into the paypoint’s bank account.
/// Prerequisites
Before you start, make sure you have the following:
- Your paypoint’s
entrypointidentifier - An API token with access to the paypoint. See the authentication recipe for help
/// Step 1: Get batches for the paypoint
Query the batches endpoint to retrieve settlement batches for a paypoint. Each batch groups transactions and, once transferred, includes a Transfer object with deposit details.
Send a GET request to /api/Query/batches/{entry}.
The response includes batch records. If a batch has been transferred, the Transfer object contains the transfer details. If Transfer is null, the batch hasn’t been transferred yet.
See List batches for paypoint for the full API reference.
/// Step 2: Get transfers for the paypoint
Query the transfers endpoint to get deposit records with adjustment details like chargebacks, ACH returns, and fees.
Send a GET request to /api/Query/transfers/{entry}.
The response includes transfer records with gross amounts, deductions, and the net amount deposited.
See List transfers for the full API reference.
/// What’s next
You’ve retrieved batches and transfers for a paypoint. To track chargebacks and ACH returns within transfers, see Reconcile adjustments in transfers. For more on how batches and transfers relate, see How money moves.
Recipe: Set up autopay on an invoice
/// OverviewSet up recurring automatic payments on an invoice by creating a subscription that references it. In this example, a customer owes 150 per month over 12 months. Each subscription payment automatically posts against the invoice.
/// Prerequisites
Before you start, make sure you have the following:
- Your paypoint’s
entryPointvalue - A
customerIdfor an existing customer. If you haven’t created one yet, see Manage customers. - Invoice details: line items, amounts, and a unique invoice number
- A
storedMethodIdfor the customer’s saved payment method. To save a method, see Save a payment method. - A schedule for the autopay: start date, end date (or open-ended), and frequency
/// Step 1: Create the invoice
Create a one-time invoice for the customer. This is the invoice that subscription payments will post against.
Send a POST request to /api/Invoice/{entry}.
In the next step, you use the same invoiceNumber to link the subscription to this invoice.
See Add invoice for the full API reference.
/// Step 2: Create a subscription with the invoice
Create a subscription that charges 1,800 invoice from step 1. The invoiceNumber in the subscription request must match the one you set when creating the invoice — this is what ties the payments to the invoice. The scheduleDetails.frequency controls when payments run, while invoiceData.frequency describes the invoice itself — keep the invoice as "onetime" and let the subscription handle the recurrence.
Send a POST request to /api/Subscription/add.
The response includes the subscription ID in responseData and the linked customerId.
See Create subscription for the full API reference.
/// What’s next
Congratulations! You just set up autopay on an invoice. Next, learn how to manage and update subscriptions and explore the full invoice lifecycle in Manage invoices with the API.