We are excited to announce our brand new integration with Dwolla! Lots of traditional credit card payment gateways have added support for ACH over the years. These APIs lowered the barrier of entry for merchants to accept bank to bank transfers. Unfortunately, virtually all implementations offer transfer times of at least 3 to 4 days. Introducing Dwolla: the company has built over the years a robust infrastructure specifically designed to offer a more modern way to access and leverage the ACH transfer network. The result reduces the transaction time down to as little one day and provides the building blocks for all sorts of integrations, business models, payment flows and end-user experiences (your users don’t even need a Dwolla account). You can trigger a payment by having your customers authenticate into their online banking account, recurring, variable payments for subscriptions are supported through On-Demand Transfers and you can even trigger payouts if you are a marketplace. Building this integration had been on our radar for a very long time, but we just never had the time to focus on it. Luckily, once again, the community helped. A consulting firm from Argentina took on the task, and they did a terrific job implementing a full solution! This new plugin supports both Dwolla Direct (co-branded product, easier to setup), as well as Dwolla White Label (for deeper, seamless experiences within your own native applications). Funding sources can be verified through both IAV (Instant Account Verification) and Micro-deposit verifications, and Dwolla.js makes sure that no sensitive payment information hits your servers. You can even configure it to listen to webhooks, to get...
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...
