Getting Started / Xformative Platform

Overview

The Xformative Platform solves financial use cases by facilitating event processing for three main features.

  • Issuing cards and other payment instruments.
  • Accepting and making payments via multiple payment channels.
  • Storing value as a result of industry accepted funds flows on a high performance ledger.

The three main features are broken into three event resource types. It is important to note, events are the commands or requests made to the Xformative Platform and events are also the associated outcomes or responses from the commands.

  • Core resources represent the business service endpoints, business payloads and business event processing. Core resources are further delineated by the following:
    • Organization resources organize the main actors of the system into a graph. Its important right now to know a few of these. Bureaus are what Xformative's calls it's business customers. Clients are what Xformative calls a bureau's business customers. Individuals are what Xformative calls a client's employees and/or patrons. A Participant is what Xformative calls an individual who is enrolled in a program.
    • Program resources manage programs, offerings, priority settings, processor settings, and card fulfillment settings.
    • Payment resources manage payment sources in addition to funding and disbursement entry transactions.
    • Card resources manage card state and card packages.
    • Ledger resources manage accounts, entries and postings.
    • View resources provide queryable views of the state of the system.
  • Batch resources represent the service endpoints, payloads and batch event processing for batch event files and ETL files.
  • Notification resources represent the service endpoints, payloads and notification event processing for event streams and web-hooks.

The Xformative Platform consists of three platform offerings, the Xformative API, Xformative Integration Resources and the Xformative Portal.

  • The Xformative API consists of core batch and subscription resources consumed by a Bureau. The core resources include organization, catalog, programs, payments, cards, ledger and wallet services. The batch resources include batch event files and ETL files. The subscription resources include event stream and web hook subscriptions.
    The Xformative API provides resources to orchestrate financial activities for nearly any business use case. Generally, businesses require the ability to store a graph of relations, accept payments, make payments, store value and issue payment vehicles such as cards.
    The Xformative API is RESTful, with an event-driven architecture that is inherently idempotent. Xformative maintains state with an event sourcing pattern.
    • An event driven architecture means Xformative's customer's enjoy high performance while executing complex operations. In addition, all events in the system can be subscribed to via web-hook or stream.
    • An idempotent service means Xformative's customers do not need to worry about retrying requests or accidentally executing the same event twice.
    • An event sourcing pattern means the state of the Xformative system is a logged sequence of events. Subsequently, Xformative's customers and their auditors can always answer how the system state was calculated. With the Xformative API event stream, your data is always your data. Xformative's customers subscribe to their event stream and subsequently are never out of sync with their own event source.
  • The Xformative Integrations, are a collection of integrations to numerous card networks, payment gateways and banks. Xformative encourages its bureaus to bring their own operating Bank, BIN and Card programs which require integration resources.
  • The Xformative Portal, also called "DOPS" which is short for developer operations portal, provides an easy way for developers to manage the Xformative API. The Xformative Portal manages invoices, team access, complex configurations, searches on the event log, batch file management and subscriptions to the event log stream and web-hooks.

Concepts

Batch Event Files

Batch event files are composed of a collection of events and used to execute events in batch for specific use cases.  Examples of batch use cases would be bulk card orders or batch transfer of accounts.

Cards API

The Cards API issues cards and maintains their state. Cards are issued payment instruments used for point of sale authorization against ledger accounts. *The Xformative Platform allows clients to optionally issue one card for multiple accounts

Developer Portal

The web application where developers can configure, manage and search data related to their API activity.

Event Driven Architecture

An event-driven architecture uses events to trigger and communicate between decoupled services. An event can carry a change in state, or an update, like an entry on an accounting ledger. Events can also be identifiers such as the notification of a card swipe.

Event Sourcing Architecture

Most systems will store just the current state of the data in a domain.  Event sourcing uses an store of appended events.  By using the full series of events, the store acts as the system of record and can be used to materialize the domain objects. Event sourcing improves performance, scalability, and responsiveness. Most importantly, event sourcing maintains the full audit trail which led to current state.

ETL Files

ETL files make it possible to transform standard or custom file formats into batch event files.

Event Stream

The Event Stream is subscribed to by a bureau.  After subscribing, the bureau will be streamed of all the executed events for that bureau, it's customers and individuals in the Xformative Platform as they happen.

Facilitator

The facilitator is the service host, gateway integrator and processor.  Xformative is the default facilitator in the Xformative Platform.

Idempotent

An action which, when performed multiple times, has no further effect on its subject after the first time it is performed

Ledger API

The Ledger API handles contribution, reimbursement, adjustment and reversal events.

Organization API

The Organization API handles profile and relation events.

Programs API

The Programs API handles program, offering and enrollment events.

Payments API

The Payment API handles payment source, funding and disbursement events.

Resource Model

Third party external custodial accounts and associated entries from which money is funded and disbursed via the ledger.

Views API

Views of programs, offerings, accounts, transaction entries, payments and issued payment instruments for organization actors.

Web Hooks

Web hooks allow a bureau to subscribe to specific events while providing a callback endpoint. The callback endpoint will be called after the subscribed to event's execution.

Resource Model

The Xformative API resource model

  • Integration consist of standard HTTP Requests, socket messages conforming to HTTP or ISO standards and files conforming to Xformative's batch event file schema or numerous approved ETL file schemas.
  • Events consist of the Xformative base event schema in addition to a specific schema that will change the state for a specific resource. At the highest level events are classified as core, batch and subscription resource events. Each resource can then subsequently be classified more specifically. Core resource events are classified as organization, catalog, programs, payments, cards, ledger and wallet. Core resources have graph and foreign key relations. Batch resources classify events as batch event files and ETL files. Subscription resources classify events as event stream and web-hook.
  • Notifications are event identifiers that publish notifications of state changes or attempted state changes by events to subscribers.

The Xformative API resource lifecycle.  

  • Http request and batch event file integration messages contain the Xformative event request to be processed. Socket message and ETL file messages contain schemas that are transformed to Xformative event requests. All messages can provide a correlation id which will be used to correlate the message, primary event and subsequent events together.
  • Once logged, the event request is routed to the appropriate event handler which triggers the processing of the event and the writing of the result to the event log.
  • Once the event is processed it publishes its status and subscribers to the event are notified.

Service Model

The Xformative Help Desk is utilized by the bureau's developers to report issues and bugs. The Xformative Portal is utilized by the bureau's developers as a customer self service portal. The Xformative API and its event stream is consumed by the bureau's developers' applications. The Xformative Integration services connect to external systems like card networks and banks.