The Transactive API has a limited number of entities which are used to tailor Transactive to your needs.
Details about your contractual relationship(s) (currently only one allowed) with Transactive, including approved products, pricing and limitations/constraints if applicable.
Members of your staff that are allowed access to Transactive.
System principals (programs/apps, not humans) that are allowed access to Transactive.
The standard Transactive bank account is a Holding account. Holding accounts act like a typical bank account. Funds that arrive are held in that account until explicitly moved out by either a Payout or a Transfer.
These accounts have a balance indicating the total funds in the account and are useful for either your house accounts or if you wants to use Seymour to manage your customer's balances.
Non-Holding accounts act like a pass-through account. Funds that arrive are instantly passed through to a single designated Holdingaccount. These funds never reside in a Non-Holding account, not even for a second.
The balance is always zero in a Non-Holding account, but there is still a record of the funds that have passed through. These accounts are most useful when you want to issue individual IBANs to your customers implementing Ibanization, but want all funds consolidated in a single Holding account. Non-Holding accounts allow you to do that in an efficient way without the need for sweeps.
Activities occur on an account. Activities include deposits, fees, payouts, transfers out and reversals.
Role-oriented permissions, used to control what Contacts and Applications can do and see.
Permission to direct payments to, and receive payments from, specific bank accounts.
URLs/endpoints in your own software system(s). Transactive will send event notifications to these Webhooks, e.g. the arrival of an inbound Payment.
In addition to configuration entities, the Transactive API has a potentially unlimited number of operational entities which are the by-product of your business activities.
Transfers of funds to and from your Accounts.
Payment-related principal or fee amounts posted to Accounts. A Payment may result in multiple entries in multiple Accounts.
Significant Payment events, e.g. the arrival of a new inbound Payment.
Payment Operating Model
The design of your integration with Transactive's API will depend on your business goals and desired payment flows. Consider the following when designing your integration pattern and consult our team when needed. We want to ensure you design and integrate the best solution for your business.
Ibanization is the assignment of a unique IBAN to every customer or individual receivable like an invoice. Read more here.