Skip to content
E-commerce platforms

velopayments.com

Velo Payments APIs sandbox and mock API

## Terms and Definitions Throughout this document and the Velo platform the following terms are used: * **Payor.** An entity (typically a corporation) which wishes to pay funds to one or more payees via a payout. * **Payee.** The recipient of funds paid out by a payor. * **Payment.** A single transfer of funds from a payor to a payee. * **Payout.** A batch of Payments, typically used by a payor to Writes persist, data moves on a schedule and every change can fire a signed webhook.

Operations
100
Collections
-
Event types
-
Start this simulation
example request
curl https://your-velopayments.slurry.io/v1/deltas/fundings \
  -H "Authorization: Bearer slurry_sim_..."

Your simulation gets its own hostname, key and IP allow-list. Built from API version 2.34.63.

What gets simulated

Collections, relationships and state machines are worked out from the spec when you start the simulation.

  • State. Creates, updates and deletes persist and show up in later reads.
  • Behaviour. Records move through their states on a schedule you control, and you can fast-forward up to 30 days.
  • Webhooks. Every change emits a signed, retried event.
  • Failure. Per-endpoint errors, latency and chaos rules, on demand.

Operations

First 12 of 100.

  • POST/v1/authenticate
  • GET/v1/deltas/fundings
  • GET/v1/deltas/payments
  • GET/v1/fundings/{fundingId}
  • POST/v1/logout
  • POST/v1/password/reset
  • GET/v1/paymentChannelRules
  • GET/v1/paymentaudit/fundings
  • GET/v1/paymentaudit/payoutStatistics
  • POST/v1/payments/{paymentId}/withdraw
  • GET/v1/payorLinks
  • POST/v1/payorLinks