Anatomy of an EFT transaction

Anatomy of an EFT transaction

One of Kill Bill most popular features is its plugin framework. At a high level, to integrate with a new payment processor, all you need is to write a plugin implementing the PaymentPluginApi, which defines the basic payment operations the gateway may support. The five most important payment operations are: authorizePayment capturePayment purchasePayment voidPayment creditPayment refundPayment If the names sound familiar, it’s because they map to the basic credit card operations: authorizePayment: perform an authorization (i.e. reserve the funds on the account but no money is moved) capturePayment: acquire the funds from an authorization (funds are settled the day of the capture) purchasePayment: acquire the funds immediately (a.k.a sale) voidPayment: cancel an authorization and free the reserved funds on the card creditPayment: credit the customer (without associated sale or capture) refundPayment: refund the customer (reverse of a sale or capture) But these actions are not limited to credit card payment methods. The BitPay plugin for example implements the purchase call for paying in bitcoins. And it turns out that the same concepts also apply for Electronic Funds Transfer (EFT) transactions (direct debit, wire, etc.). A payment processor which offers EFT APIs will typically work with a bank (similar to acquiring banks in the case of credit cards) to which it will forward the debit requests. Settlement (when your merchant account receives the funds) usually occurs after the customer funds have arrived into the processor’s bank account, although some processors will fund in advance to speed up the process (bearing the risk funds may never come). While in its simplest form, a debit transaction can be seen as a simple...

Kill Bill: Billing System Architecture

This post is a high level description of the architecture of Kill Bill as a billing system. The intent is to describe briefly the various core components and how they interact with one another. The diagram below shows the main core services in Kill Bill: At the bottom of the stack, we have the catalog service, whose role is to provide the catalog information that is pertinent to a given tenant. The catalog service offers an API to retrieve product information, alignment rules, prices,.. The entitlement service offers an API for managing all the entitlement information associated to a given subscription — its state (started, paused, resumed, stopped,…), its ownership, the various dates where state transition,… The entitlement system offers a different view than what is reflected in the invoices to allow fine tuning of what should be billed versus how the service is provided. In addition to that API, it will generate (persistent) bus events that other services can register to. The invoice service offers an API to retrieve past invoices, make any adjustments, or even trigger future invoices. In addition to that API, it will generate bus events that other services can register to. The payment system offers an API to retrieve past payment/refund information or to trigger new payments/refunds.  In addition to that API, it will also generate bus events. The overdue system is a generic system that is driven through a configuration, to take action when payments are failing and users end up not paying. A complex set of phases can be implemented to gradually terminate the service, notify the users, … if needed. It also offers an...