ACME Payments documentation is a draft & work in progress.  Updates may be published periodically.  


TABLE OF CONTENTS

Overview

Payment Processing


ACME payment APIs are designed for server-to-server communication in order to provide maximum flexibility and work from the more secure server environments. We also provide foundational payment Javascript (acme.js) to help you descope your server from PCI if desired.


Our payment API layer is made of the key 5 payment primitives (authorization, void, capture, sale, refund) and tokens for payment methods on file. From this layer most simple applications, with simple payment use cases, can be built with a small development lift. 


Within the payment APIs, the processing APIs, capture/sale, share common request data, therefore we model their input with a reusable Charge object to make your application development simpler. The difference between the processing APIs will relate to the payment method being used, either a one-off type of charge or for recurring charge use cases, such as card on file.  Therefore the overall orchestration of the payment lifecycle can be illustrated as:

  1. Acquire a token of either one-time usage or multiple-use type from an input payment method. This can be done via JS or APIs.
  2. Use the token to either use the Sale API with a Charge or authorize for a later capture of the Charge. 
  3. Cancel payments either via an authorization Void or Refund if the payment was processed.


Note that online e-commerce use cases where the goods are paid upon checking out, the Sale API, Refund, and token constructs are the only functions needed, simplifying the scope of your integration.


Seller Onboarding


We provide an instant provisioning API to immediately map your application payment calls with a MID (merchant ID) , supported by incremental onboarding update APIs to add the remainder of the data for the full underwriting and provisioning of the seller. Based on the development front end lift on your end and/or need for quickly getting a seller to be able to transact, you can choose between the APIs and/or a mix of the ACME provisioning team to help bring a seller up in short 1-2 days SLAs.


Versioning

  • Sub major version revisions, major being the version in the URL, the sub-version of the API can be requested via HTTP x_acme_api_version request header.

  • As a rule of thumb, our APIs are defined to be backward compatible in that the response objects do not remove data, and we add data only, as we have done with our point of sale and scanner applications deployed on-prem, and connected to our back end.

 

Use Cases

High-level use cases that can be achieved with this set of Payment Primitive APIs

  • One Time Payment - customer pays for the product immediately at the time of checkout (requires: Payment token and Sale API)



  • Cancel Deferred Payments - customer saves a new payment method on file and agrees to pay for a product later but then later they cancel the order before the first charge. (requires: Payment token, Authorization API and Void API)


  • Recurring payments - a customer agrees to pay for something on a scheduled/recurring basis using a saved card on file. (requires: Payment token, Authorization API)


  • Refund a partial or full payment - a customer cancels some or part of their order (requires: Payment token, Refund API)

 

Future

Payment methods - we will expand our payment method offering beyond credit card to ACH, Apple and Google pay, and more over time.  


We will also complement the payment primitive APIs with additional more advanced services, such as subscriptions, donations, events, memberships, and card-present use cases, to help reduce the development lift on the application builder.  Our core ticketing and membership clients are using these APIs today, and they will be folded into our Payments vertical over time.  Our ticketing, membership and donation APIs can be found here.