ACME Payments documentation is a draft & work in progress. Updates may be published periodically.
TABLE OF CONTENTS
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:
- 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.
- Use the token to either use the Sale API with a Charge or authorize for a later capture of the Charge.
- 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.
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.
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)
- Deferred Payments - customer saves a new payment method on file and agrees to pay for a product later. The sale is completed 5 days later. (requires: Payment token, Authorization API and Capture 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)
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.