Overview


ACME payment APIs are built from the ground up to enable multi-party payments whereby you as an ISV/Saas player can bring to your sellers/ merchants your own integrated payment features. N


Our 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 an SDK for processing card present payments, including Apply Pay and google Pay, via your web application.


Our payment API layer is made of key payment primitives for sales and refunds, supporting both one time charges and use cases for recurring charges, such as card on file. From this layer most simple applications, with simple payment use cases, can be built with a small development lift. 

 

Getting Started

Making an API Call

All ACME Payment URLs are HTTPS based only and  have the format api.acmepayments.com/v1/payment/[MerchantId]/* and require a header value for x-acme-payment-key

  • MerchantId: is a unique identifier assigned by ACME for this seller.
  • PaymentKey: is a secret value assigned to the software developer. This is essentially your password and should be protected. The PaymentKey should only be used for server to ACME calls and never be shared, put in front end code or a public github repository.


Use Cases

High-level use cases that can be achieved with the ACME Payments APIs:

  • One Time Payment - customer pays for the product immediately at the time of checkout 
    • ACME makes it easy to accept payments from customers that you won't be storing their card on file for. This is done by generating a single-use token with their credit card information (see Token API) and then charging against that token when the customer has confirmed their purchase (see Sale API).

  • Recurring and Deferred Payments - a customer agrees to pay for something on a recurring basis or on a future scheduled date using a saved card on file.
    • ACME gives you an easy way to provide the convenience of storing the card on file for the customer. That way the customer only needs to enter their credit card information once. You can pass in your customer ID and payment method ID for later reference when charging against a card on file or managing the customer's cards on file. (See Token API)

    • Making a sale with a card on file is done by providing the amount for the sale and either the token of the card on file or the externalPaymentMethodId that you provided. (See Sale API)

  • Manage Cards on File - a customer needs to review or edit their cards
    • Sometimes customers might want to see which cards you have on file for them and remove cards that are no longer valid. Use your customer ID you provided when creating the card on file to list the cards that a customer has on file. You can also look up an individual card on file using either the token for the payment method or the payment method ID that you provided. (See Token API)


  • Refund a Payment (partial or full refund) - a customer cancels some or part of their order 
    • ACME gives you an easy way to refund payments. Refund the entire amount, or a portion as needed.  (See Refund API)

  • Card Present Transactions - a customer pays for something using an ACME provided card reader (See SDK - Card Present Sales)
     
  • Get Transactions - provide your sellers with a dashboard to let them know what transactions have taken pace. 
    • ACME makes it easy to get an individual transaction or a list of transactions, including sales and refunds, for use within your platform (See Transactions API)

 

Future Development

We plan to expand our payment method offering beyond credit card to ACH, Gift Cards, and more over time. 


We will also complement the payment primitive APIs with additional more advanced services, such as subscriptions, donations, events, and memberships, 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.


We will 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.