Every payment in, matched on arrival.

Collect inbound payments on the payer's rail into your Infinite Account, screened before funds land and matched on arrival.

EVERY PAYER SCREENED · EVERY PAYMENT MATCHEDILLUSTRATIVE
Who it’s for

Payins on Infinite are inbound payments into an Infinite Account: funds sent to you over SWIFT, US rails, stablecoins, or FX. Every payer is screened before funds land, and each payment is matched to the request, invoice, or customer it belongs to.

  • Finance teams collecting from customers in several countries and currencies
  • Platforms taking in funds on behalf of their own customers, each in their own account
  • Businesses replacing a collections provider per rail and per country with one account
Example

One customer pays, three ways.

A software company bills customers in the US, Europe, and Brazil. Each pays the way they already pay.

01

Each customer gets an account number

On onboarding, every customer is issued a Virtual Account under the company. Their invoice carries it.

02

They pay on their rail

The US customer sends ACH, the European customer pays in euros, the Brazilian customer settles in stablecoins.

03

Each payer is screened

Sanctions, watchlists, and the network record run before funds land. A payer already cleared on the network clears instantly.

04

Funds land and match

Each payment settles into the company account, converts where needed, and reconciles to the invoice it answers.

05

One ledger, month closed

Receivables sit on the same ledger as balances and payables, with one audit trail.

Developers

Integrate once.

Issue a payer their account number once; inbound payments arrive as events with the payer, rail, and matched object already resolved.

listen-for-payins.tsILLUSTRATIVE EXAMPLE
const account = await fetch("/v1/virtual-accounts", {
  method: "POST",
  headers: {
    Authorization: "Bearer " + apiKey,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    parent: "acct_ops_usd",
    customer: "cus_2201",
  }),
});
 
// payin.settled webhook: payer screened, funds landed, invoice matched
FAQ

Answers before you ask

How are Payins different from Links and Invoicing?

Links and Invoicing are how you ask a payer to pay: a shareable request or a document with payment instructions. Payins is the payment itself arriving: which rail it came on, who sent it, whether it cleared screening, and what it matched to. Every Link and Invoice that is paid becomes a payin; so does a payment a customer sends without being asked.

Which rails can a payer use?

SWIFT wires, US rails (ACH, Fedwire, RTP), stablecoins, and payments in another currency converted by FX in flight. They all settle into the same Infinite Account and reconcile in the same place.

Are inbound payments screened?

Yes. The payer is screened before funds land, on every rail: sanctions, watchlists, and the network’s own counterparty record. A payment that is flagged holds for a named analyst, with the case assembled through Compliance AI, and nothing lands silently.

How does a payment get matched to the right customer?

Give each payer their own account number through Virtual Accounts. A payment into that number identifies the customer by itself, with no reference field to mistype, and reconciles to the open Link or Invoice it answers.

Can a platform collect on behalf of its customers?

Yes. That is third-party funds flow: each of your customers holds their own account on the network, inbound payments land in the right one, and the compliance program Infinite already operates covers every payer.

From their bank to your ledger.

Talk to an engineer. Bring the rails your customers pay on and we’ll walk one payment through.

Ask an AI about PayinsChatGPTClaudePerplexityGemini