Guides introduction
Swirepay splits product documentation into Payment Center (money you receive) and Transfer Center (payables, contacts, transfers, and vendor invoices). Use the sections below to choose where to start, then follow the guides in the sidebar.
Authenticating API requests
Payment Center and Transfer Center REST APIs share the same authentication model: include your API key on every request using the x-api-key header (many clients and docs also refer to X-API-Key).
- Create and rotate keys in the Swirepay Dashboard under Developer.
- Use
https://api.swirepay.comas the production base URL unless your integration explicitly targets another environment listed in the API reference.
Some flows return a pre-signed S3 URL for file uploads (Transfer Center bulk Excel import). See Bulk Upload. Upload with PUT to the pre-signed URL without attaching Swirepay API-key headers.
For response envelopes, errors, and platform-wide topics, see Getting Started (main API documentation).
Payment Center
Swirepay is a full-stack payment platform built for businesses that need reliable acceptance and flexibility across how and where customers pay. Whether you operate online, in person, or through partner systems, Swirepay brings card, bank, and wallet experiences together behind a consistent model for creating payment sessions, tracking status, and reconciling what you have collected.
Payment methods your customers can use
Swirepay supports the payment types modern buyers expect, so you can meet customers on the rails they prefer without stitching together separate vendors for each brand. Supported options include card networks, ACH bank debits, Apple Pay, Google Pay, Venmo, PayPal, and Zelle. Together, these methods cover everything from traditional card checkout to bank-account payments and popular digital wallets, which helps reduce friction at checkout and supports a wider set of use cases—from consumer retail to invoicing and subscription-style billing.
One-time, recurring, and faster cash flow
Not every business bills the same way. Swirepay supports one-time charges for carts, invoices, and ad hoc payments, and recurring payments for memberships, installments, and other schedules that repeat on a cadence you define. On the bank side, faster ACH settlement options (where available for your program) can shorten the time between a successful debit and usable funds, which matters for inventory, payroll, and tight operating cycles.
Where payments happen: Web, SDKs, POS, kiosk, and integrated systems
Swirepay is not limited to a single channel. You can accept payments on the web—for example in a browser checkout you host, embed, or redirect to—and in native and mobile apps using Swirepay SDKs so card, wallet, and bank flows stay consistent in your client code. The same platform supports in-person acceptance on a point of sale (POS) terminal, through a kiosk for self-service lanes, and inside integrated systems such as custom backends, billing engines, and back-office tooling. Payment Center sits behind these surfaces as the operational layer for the payments you receive, so your teams can reason about one set of objects and statuses even when the customer experience differs by channel.
What Payment Center is
Payment Center is the Swirepay surface that handles all the payments you receive. It is where inbound payment activity is created, authorized or confirmed (depending on method), settled, and made visible for operations and finance. When you build on Payment Center, you are aligning your integration with the same lifecycle your dashboard and reporting use, which reduces ambiguity when you debug issues or close the books.
Conceptually, think of Payment Center as the system of record for money coming in: payment sessions and their outcomes, the methods used, and the trail you need to support customer service and reconciliation. The guides under Payment Center in the sidebar walk through how to work with those flows in practice.
Webhooks for Payment Center
Synchronous API responses tell you what happened in the moment of the call, but many payment journeys finish asynchronously—think bank processing, wallet redirects, retries, or downstream updates from networks and partners. Swirepay exposes webhooks that your backend can consume for payment lifecycle events. See the Webhooks guide for configuration and Webhook delivery & payloads for technical verification details.
Start with Payment Center guides →
Transfer Center
Transfer Center is where you move money out—to vendors, customers, internal treasury positions, and virtual accounts—and where you run payables workflows (contacts, bank rails, transfer sessions, and vendor invoices). It complements Payment Center: Payment Center is inbound acceptance; Transfer Center is programmatic control over who you pay, from which funding sources, and how those movements are tracked from creation through settlement.
Contacts, funding sources, and rails
Everything downstream assumes you can identify contacts (people or entities you pay or move money between) and attach funding sources—bank rails backed by an issuer bank record or balances held in a virtual account. Contacts carry types such as vendor, customer, SELF (your own entity), and virtual account, which lets you model both external payees and internal books on the same APIs.
Typical first steps are: create and search contacts, add funding sources per contact, and optionally send funding source links so a counterparty completes bank details through a hosted flow. For scale, use Bulk Upload (Excel: contacts + links, or direct funding sources). Virtual accounts expose balance and threshold fields in list responses so treasury views stay aligned with what the API sees—without bolting on extra balance endpoints for every screen.
Transfer sessions and payouts
Transfer sessions are the core unit for moving funds between a payer funding source and a beneficiary funding source: you create a session with amounts, currency, transfer type, and the relevant GIDs, then track status, timelines, and optional per-session notify hooks. Treat the session’s status as the source of truth—even when HTTP returns success, issuer-side processing can still end in a declined outcome.
For payroll-style or AP batches, multi-transfer accepts many sessions in one request and exposes batch-level listing and detail so operations can reconcile volume without chatty single-session loops. Internal-style movement (SELF and virtual-account contacts) uses the same transfer-session API; only the contact and funding-source pairing changes—see the dedicated guide for valid combinations and balance reads alongside internal flows.
Vendor invoices (payables)
When your workflow is invoice-driven, vendor invoices attach amount, dates, contact, and funding context to a structured lifecycle: draft → activate → pay, with optional notify when you want to trigger payer-facing communications from your integration. Status on the invoice entity tells you which transitions are valid next; pairing this with webhooks reduces reliance on polling alone as invoices and payouts progress.
Notifications, webhooks, and the dashboard
Not everything is configured through REST. Account-level notification policy for Transfer Center—what gets sent, when, and to whom—is set in the Dashboard under Transfer Settings. API operations such as notify transfer session or notify vendor invoice are explicit triggers for specific resources; they do not replace dashboard policy.
For event-driven integrations (transfer or invoice lifecycle, and related catalog entries), configure HTTPS endpoints and secrets in the Dashboard and follow the shared Webhooks guide for signing, retries, and payloads; Transfer-specific events sit alongside Payment Center and inventory in the same model. Missed deliveries should be reconciled with GET APIs—webhooks are at-least-once.
Support: support@swirepay.com · swirepay.com