Migrating from Tipalti to Lumanu

This guide is for platforms on Tipalti that pay creators, affiliates, streamers, or other marketing-economy vendors, and are evaluating a move to Lumanu.

❗️

Required Reading

If you haven't yet, start with Why wallet-based payments?. This guide focuses on the mechanics of migrating off Tipalti.

Is Lumanu the right fit?

Tipalti is a broad platform, used for marketing-economy payouts (creators, affiliates, streamers, game developers) and for enterprise accounts payable: supplier payments, PO matching, ERP-integrated bill pay, multi-entity corporate structures.

This guide is about the first use case only. If your Tipalti setup is centered around:

• Paying individual creators, affiliates, talent, or performers
• Recurring vendors (not one-off bills)
• A product surface that's consumer- or creator-facing rather than AP-centric

…then Lumanu is likely a good fit, and this guide applies.

If your Tipalti setup is primarily:

• AP workflows with approvals, PO matching, and ERP (NetSuite, SAP, Oracle, QBO) integration
• Supplier payments for goods/services where the supplier relationship is transactional
• Bill-pay against invoices from suppliers

…Tipalti is probably the right tool for that workload. Lumanu's model optimizes for different things. Some platforms end up splitting: creator/marketing payments go to Lumanu, traditional AP stays on Tipalti. That's a reasonable target state.

Mental model shifts

From batch AP runs to event-driven credits

Tipalti's default cadence is the payment run. Invoices accumulate, approvers approve, a batch is processed weekly or biweekly. The mental model is periodic reconciliation: your platform computes what's owed, your finance team approves, payments go out on schedule.

Lumanu's cadence is event-driven. When something in your product earns a creator money, you create a payable. When it's ready to pay, you fund it. There's no "payment run" concept; funding happens as business events warrant, in real time.

The practical consequence: the cron jobs, scheduled batch-builders, and approval queues your team built around Tipalti's payment runs become either unnecessary or much smaller.

From per-payer payees to network vendors

In Tipalti, a payee is scoped to a payer (or payer entity). The same creator working with two Tipalti customers has two separate payee records: two onboardings, two W-9 submissions, two Supplier Hub profiles to keep in sync.

In Lumanu, vendors exist once in the network. A creator who's onboarded with any other Lumanu buyer is already verified when you invite them. New vendors onboard once, then are available to every buyer in the network.

For creator-focused platforms, this is often the headline benefit. Support ticket volume around "why do I have to fill out another W-9?" drops sharply.

From push payments to credited wallets

Tipalti pushes funds to the payee's chosen payment method: ACH, wire, PayPal, check, card, local rails. Your platform cares about whether that push succeeded, failed, was returned, or needs retry.

Lumanu credits a wallet the vendor owns. The vendor withdraws on their own schedule to their own chosen destination. Push-failure and return events happen between the wallet and the vendor's bank, outside your system.

Tipalti's "cash-out" feature (common in gaming) foreshadows this model: it gives payees self-service withdrawal from an accrued balance. Lumanu is structurally built around that pattern as the default, not as an add-on feature.

Terminology map

API mapping

Tipalti has two API surfaces: the long-standing SOAP API (Payer/Payee functions) and a newer REST API. Operation names are stable across both; the examples below use SOAP names since they're most commonly referenced. Your REST equivalents use the same verbs and nouns.

Onboarding a vendor

Tipalti (two common patterns):

API: create the payee record and send them to the Supplier Hub.

UpdateOrCreatePayeeInfo(
  idap: "CREATOR_1234",
  FirstName: "Alex",
  LastName: "Creator",
  Email: "[email protected]",
  SendSupplierPortalInvite: true
)

iFrame: generate an HMAC-signed iFrame URL and embed or redirect.

https://ui.tipalti.com/.../iframe?idap=CREATOR_1234&payer=YourName&ts=<ts>&hashkey=<hmac>

Lumanu has the same two options: API invite or redirect flow.

API invite:

await fetch(`${LUMANU_BASE}/workspace/${workspaceId}/partner/invite`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    invites: [{
      payee_email: '[email protected]',
      payee_business_name: 'Creator LLC',  // optional
    }],
  }),
});

Redirect flow (vendor_invite_url, analogous to the Tipalti iFrame):

const res = await fetch(`${LUMANU_BASE}/workspace/${workspaceId}`, {
  headers: { Authorization: `Bearer ${token}` },
});
const { vendor_invite_url } = await res.json();
// Example URL:
//   https://use.lumanu.com/public/invitation/get-paid?invitationId=<workspace-id>
window.location.href = vendor_invite_url;

Two differences from Tipalti:

• No HMAC signing of the URL required. The vendor_invite_url is stable per workspace and can be cached.
• No idap to assign. Lumanu identifies vendors by email or by their Lumanu ID. Keep your own internal reference in your own database, mapped to the vendor's email.

Checking whether a vendor is payable

Tipalti:

GetExtendedPayeeDetails(idap: "CREATOR_1234")
// Inspect Status field: "Payable" vs "Not Payable"
// Also check TaxFormStatus and PaymentMethodStatus

Lumanu:

const res = await fetch(
  `${LUMANU_BASE}/workspace/${workspaceId}/partner/${partnerId}`,
  { headers: { Authorization: `Bearer ${token}` } }
);
const partner = await res.json();

A behavioral difference worth noting: Tipalti requires payable status before you can submit payment. Lumanu lets you create payables against unverified vendors. They sit in approved and settle into the vendor's wallet once verification completes. If your product flow benefits from "queue first, clear when ready," Lumanu's model removes a blocking check.

Submitting a payment

Tipalti (create an invoice, then process payment, or submit a payment file):

CreateOrUpdateInvoices([
  {
    idap: "CREATOR_1234",
    ref_code: "CAMPAIGN-Q2-2026-001",
    date: "2026-04-01",
    due_date: "2026-05-01",
    subject: "Q2 Campaign Content Creation",
    currency: "USD",
    line_items: [{ amount: 1500.00, description: "Instagram Content Creation" }]
  }
])

// After approval (manual or auto):
ProcessPayments(payment_orders: ["CAMPAIGN-Q2-2026-001"])

Lumanu (create payable, approve, fund):

// 1. Create payable
const create = await fetch(`${LUMANU_BASE}/payable`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    workspace_id: workspaceId,
    payee_email: '[email protected]',
    amount: 150000,                          // cents
    amount_denomination: 'us_cents',
    description: 'Q2 Campaign Content Creation',
    due_date: '2026-05-01T00:00:00Z',
    send_invite: true,
    line_items: [{ amount: 150000, description: 'Instagram Content Creation' }],
  }),
});
const { payable } = await create.json();

// 2. Approve
await fetch(`${LUMANU_BASE}/payable/${payable.id}/approve`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}` },
});

// 3. Fund
await fetch(`${LUMANU_BASE}/funding`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    workspace_id: workspaceId,
    method: 'balance',                       // or 'invoice' for pay-by-bank-transfer
    amount: 150000,
    amount_denomination: 'us_cents',
    description: 'Q2 Campaign payout',
    payable_ids: [payable.id],
  }),
});

To emulate a Tipalti payment run (many invoices, one processing event), create N payables individually, then include all their IDs in a single POST /funding call. That call is the direct analog of ProcessPayments over a batch.

Approval workflows

Tipalti supports rich multi-level approval chains configured in the Tipalti Hub: approver 1, approver 2, category-based routing, threshold-based escalation.

Lumanu's payable model has a single approve action. If your current workflow needs multi-level approval with named reviewers, thresholds, or category routing, implement that in your own product (or an external approval tool) and only call POST /payable/{id}/approve once your internal approval completes.

For simpler approval flows (one reviewer, one approval), map directly: your current Tipalti "ready to pay" state becomes the Lumanu approve call.

IPNs vs webhooks

Subscribe via POST /workspace/{id}/webhook-subscription. Authentication is Bearer token instead of Tipalti's HMAC signing.

Funding your wallet

Tipalti is pre-funded: you load your payer entity's account via wire/ACH before a payment run. Lumanu is also pre-funded, with two methods:

• balance: transfer into the workspace wallet's account/routing numbers, then settle payables from that balance. Closest to Tipalti's model.
• invoice: Lumanu generates a funding invoice tied to specific payables. Your AP pays it; the incoming deposit arrives unlinked; you match it to the funding; payables then clear (unless also waiting on vendor verification). Useful when your AP team wants a PO or invoice to reference.

The invoice flow has four steps:

// 1. Create the funding (generates an invoice)
const fundingRes = await fetch(`${LUMANU_BASE}/funding`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({
    workspace_id: workspaceId,
    method: 'invoice',
    amount: 5000000,
    amount_denomination: 'us_cents',
    description: 'April 2026 creator payouts',
    po_number: 'PO-12345',
    payable_ids: payableIds,
  }),
});
const { funding } = await fundingRes.json();

// 2. Retrieve the invoice PDF for your AP team
// GET /funding/{id}/pdf-url

// 3. AP pays via bank transfer to the workspace wallet's
//    account/routing numbers. The deposit arrives unlinked.

// 4. Match the deposit to the funding
const unlinkedRes = await fetch(
  `${LUMANU_BASE}/workspace/${workspaceId}/wallet/deposit`,
  { headers: { Authorization: `Bearer ${token}` } }
);
const { deposits } = await unlinkedRes.json();

await fetch(`${LUMANU_BASE}/funding/${funding.id}/link-deposit`, {
  method: 'POST',
  headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
  body: JSON.stringify({ deposit_id: deposits[0].id }),
});

Once linked, payables in the funding settle. If they're also waiting on vendor verification, they settle the moment the vendor completes onboarding. Tipalti's pre-fund-then-draw-down model has no matching step. Under Lumanu's invoice method, the match is an explicit call that you can automate (poll unlinked deposits, match on amount and timing) or handle manually via a finance UI.

Flow comparison

Onboarding a creator

Tipalti (API path):
  Platform  →  UpdateOrCreatePayeeInfo                 →  Tipalti
  Tipalti   →  emails Supplier Hub invite
  Creator   →  onboards (ID, bank, tax)                →  Tipalti
  Tipalti   →  IPN: payee status → Payable             →  Platform
  Platform  →  check GetExtendedPayeeDetails before paying

Tipalti (iFrame path):
  Platform  →  generate HMAC-signed iFrame URL
  Platform  →  embed or redirect creator to iFrame
  Creator   →  onboards within iFrame                  →  Tipalti
  Tipalti   →  IPN: payee status → Payable             →  Platform

Lumanu (Option A, API invite):
  Platform  →  POST /partner/invite                    →  Lumanu
  Lumanu    →  emails creator
  Creator   →  onboards to Lumanu network (once, ever)
  Platform  →  optionally poll partner status

Lumanu (Option B, redirect flow):
  Platform  →  GET /workspace/{id}  (reads vendor_invite_url)
  Platform  →  redirect creator to vendor_invite_url
  Creator   →  onboards to Lumanu network (once, ever)

For creators already in the Lumanu network, Option B is particularly smooth. They land, authenticate, and are attached to your workspace without re-verifying.

Paying a creator

Tipalti:
  Platform  →  CreateOrUpdateInvoices                  →  Tipalti
  (Approval workflow: manual or auto)
  Platform  →  ProcessPayments                         →  Tipalti
  Tipalti   →  pushes to creator's payment method
  Tipalti   →  IPN: payment submitted / sent / error   →  Platform

Lumanu:
  Platform  →  POST /payable                           →  Lumanu
  Platform  →  POST /payable/{id}/approve              →  Lumanu
  Platform  →  POST /funding                           →  Lumanu
  Lumanu    →  credits vendor's wallet
  Vendor    →  withdraws on their schedule, their rail

Data migration

Vendors

Export your Tipalti payees (via Tipalti Hub export or the CreateExtendedPayeeStatusFile / REST equivalent). Filter to those with status Payable: these are the ones you have a working relationship with. Invite each to your Lumanu workspace.

// Pseudocode: once you have a list of payable Tipalti payees
const invites = tipaltiPayees
  .filter(p => p.status === 'Payable')
  .map(p => ({
    payee_email: p.email,
    payee_business_name: p.companyName || `${p.firstName} ${p.lastName}`,
  }));

// Split into chunks if large; batch-invite
for (const chunk of chunks(invites, 100)) {
  await fetch(`${LUMANU_BASE}/workspace/${workspaceId}/partner/invite`, {
    method: 'POST',
    headers: { Authorization: `Bearer ${token}`, 'Content-Type': 'application/json' },
    body: JSON.stringify({ invites: chunk }),
  });
}

Keep your Tipalti idap values in your own database, mapped to each vendor's email. You'll need them during reconciliation for the cutover period.

Identity, banking, and tax info

Don't migrate these. Even if Tipalti could fully export them (it can't, for sensitive fields), Lumanu's network verification runs independently and wouldn't trust imported data. Vendors re-verify once with Lumanu.

Tipalti users tend to have high-volume, long-standing creator relationships; a sudden, unexpected invite email generates support tickets. Good practice:

• Email all active payees 1–2 weeks before sending Lumanu invites, explaining the change
• Surface the vendor_invite_url as a "Set up Lumanu payments" button inside your product, for vendors who prefer not to click email links
• Prepare your support team with an FAQ covering "why am I getting an email from Lumanu?"

In-flight invoices and payments

• Invoices already paid. Nothing to do.
• Invoices approved but not yet in a payment run. Either let Tipalti process one final payment run for this batch, or cancel and recreate as Lumanu payables. Canceling mid-flight is more error-prone; a final Tipalti run is usually cleaner.
• Invoices pending approval. Decide per-invoice whether to finish approval in Tipalti (and pay through Tipalti) or cancel and recreate in Lumanu. New approvals should generally move to Lumanu or your own workflow from cutover forward.
• Future obligations. Create as Payables in Lumanu from cutover forward.

Lock CreateOrUpdateInvoices behind a feature flag at cutover so nothing new is created in Tipalti during the transition.

Multi-entity setups

If you have multiple Tipalti payer entities (say, one per region or business line), create corresponding Lumanu workspaces: one per entity. Each workspace has its own wallet, its own vendor list, and its own funding. Don't try to consolidate multiple Tipalti entities into a single Lumanu workspace; the separation exists in Tipalti for a reason (accounting segregation, compliance) and that reason carries over.

Feature parity and gaps

Things Lumanu does that Tipalti doesn't (or doesn't emphasize):

• Network-wide vendor identity. Creators onboarded anywhere in the network are available to every buyer. The single biggest Tipalti migrator complaint, per-payer re-onboarding, goes away.
• Real-time funding model. No payment-run cadence required. Fund as events warrant.
• Network-level tax reporting. Lumanu is the 1099-NEC / 1042-S filer, not your entity.

Things Tipalti does that Lumanu doesn't:

• Deep ERP integration. NetSuite, SAP, Oracle, QuickBooks, Sage Intacct: Tipalti's ERP connectors are extensive and bidirectional. Lumanu doesn't currently offer equivalent ERP connectors. If your Tipalti usage is ERP-coupled (bills syncing both ways, GL coding per invoice, auto-reconciliation), that integration surface needs to be rebuilt or kept on Tipalti for the AP use case.
• Multi-level approval workflows. Named approvers, threshold-based routing, category routing, approver delegation: all configured in the Tipalti Hub. Lumanu has a single approve action; richer workflows move into your own product.
• PO matching and procurement features. Not in Lumanu's scope.
• 50+ payment methods, 120 currencies. Lumanu's vendor-chosen wallet withdrawal covers most major rails, but if a payee relies on specific exotic-rail requirements, verify coverage with Lumanu's team before cutover.
• Self-billing invoices. Tipalti can auto-generate invoices on behalf of payees. Lumanu's POST /payable is the closest equivalent (you create the obligation), but the concept of a payee-approved invoice doesn't directly exist.
• Cash-out/on-demand withdrawal for payees. Tipalti's cash-out lets payees request withdrawal from an accrued balance. Lumanu's entire model is effectively this (the wallet is the accrued balance), but it's structurally different, not a feature you toggle.

Rollout strategy

1. Weeks 0–2: sandbox and scope. Build against https://api.demo.lumanu.link/api/rest. Scope carefully: decide which payee populations move (creators) and which stay (suppliers, ERP-coupled bills). Map Tipalti entities to Lumanu workspaces.
2. Weeks 2–4: parallel integration. Implement payable creation, approval, and funding flows alongside existing Tipalti code paths. Do not yet route live traffic.
3. Weeks 4–6: new creator signups to Lumanu. Flip new signups to onboard through Lumanu. Existing creators remain on Tipalti. Measure Lumanu funding, webhook reliability, and creator completion rates.
4. Weeks 6–12: communication and migration waves. Batch existing creators into migration waves (by region, by tier, or by volume). Each wave gets advance notice, then invites. Route payments per-creator as each completes Lumanu onboarding.
5. Months 3–6: residual cleanup. Creators who haven't migrated after multiple reminders get a final Tipalti run with a deadline notice. Non-creator payees (if any) remain on Tipalti indefinitely or migrate to a different solution appropriate for their workflow.
6. Year-end: tax reporting handoff. Plan explicitly for the first year-end after cutover. Your finance team needs to know that 1099/1042-S forms for migrated creators will be issued by Lumanu, not your entity. Ensure your year-end reconciliation accounts for this.

Expect migration to take months, not weeks, especially if you have multiple entities or ERP-coupled workflows. A hard cutover across all creators in a single date window is not recommended.

Gotchas

• Keep your idap mapping. Your internal vendor reference (what you pass to Tipalti as idap) still matters inside your own system. Map it to each vendor's email so you can reconcile Tipalti and Lumanu records during the transition period.
• ERP integrations don't transfer. If your Tipalti integration writes bills back to NetSuite/SAP/QBO with GL coding, that wiring is Tipalti-specific. You'll need to either rebuild equivalent sync against Lumanu's funding/payable data or keep ERP-coupled bills on Tipalti.
• Approval workflows need a home. If multi-approver routing is critical to your finance process, decide where it lives post-migration: in your own product, an external tool, or stay on Tipalti for that workload.
• Tax reporting transition year will be messy. In your cutover year, some creators will have earnings reported by your Tipalti payer entity and some by Lumanu. Loop in finance and tax counsel well before year-end. Confirm with Lumanu's team how pro-rated 1099 issuance works for creators migrated mid-year.
• Supplier Hub brand vs. Lumanu brand. If your creators are used to seeing your brand on the Supplier Hub, switching to Lumanu-branded invite emails and onboarding will be noticeable. A brief explainer in your creator docs and support FAQ pre-empts the tickets.
• "Not Payable" isn't a blocker. In Tipalti, unpayable status stops you from submitting payment. In Lumanu, you can create payables anyway and they settle when verification clears. This is a feature, but it changes how you think about product-flow gating.
• Rate limits. Lumanu's standard tier is 100 requests/minute. If you're currently batching payment file uploads via SFTP or running large API bursts against Tipalti's relatively generous limits, plan chunking accordingly.
• SOAP-to-REST mindset shift. If your Tipalti integration is SOAP-based with HMAC-signed requests, the Lumanu REST + Bearer token model will feel simpler, but double-check error handling paths. The error surface looks different.

Resources

• API Reference - Full endpoint details
• Sandbox: https://api.demo.lumanu.link/api/rest
• Production: https://api.lumanu.com/api/rest