ACME online core payment APIs
We are excited to announce the sandbox Beta release of the ACME online core payment APIs, which build upon our payments platform. This release makes it fast and easy for you, B2B application makers, to generate meaningful revenue from payments when integrated with your online products. Coming soon, we will deliver omnichannel integrated payments, for card-present use cases.
Built on our robust and scalable API-centric payments platform
The long journey of this effort goes back to the founding of the company when we set out to build, over many years, a robust and scalable API-centric payments platform, whose initial consumption was our application layer.
We did this so our clients could grow by delivering key benefits such as a single-seller solution for online and Point-of-Sale (POS) scenarios and competitive transaction costs facilitated by the platform. All along, given the ticketing/membership/donations industries are so diverse in use cases, and hence served by so many different application makers, we knew that, as our API platform matured, our focus on the common integrated payment use cases could be turned into a cloud service to help you, application makers, grow as well.
Those benefits are now available to you with minimal development effort by accessing our API-centric platform.
A new model
Let us start by explaining why we made the decisions we made and how you can leverage this knowledge as you consider integrating payments into your applications.
When participating in the payment revenue, the key is to move your sellers from their Merchant of Record (MOR) into your software, provide more value and better pricing, or replace your payment provider if they lack functionality and have poor revenue sharing.
ACME was able to accomplish this by applying to bring better economics and value to our customers. In the payment processing world, transaction costs are charged to the MOR holder. As the payment platform, we went with a specific regulatory model whereby we became the master MOR. Our sellers became what we call sub-merchants, however, without the need for an actual MOR account.
The implications of this model are paramount
1/ Since the transaction costs reduce with increased seller volume, economies of scale will quickly improve your finances. We can now pass along those economies of scale via a tiered rate card to you, wholesale pricing if you will, that can be turned, with a daily pay-out spread, into your direct retail pricing as you see fit.
2/ Given that fraud costs are also transaction costs and we, as the platform, are the master MOR, we had to invent a new native integrated fraud shield to limit the financial downside of card attacks on our sellers’ websites. With this capability already in place, there is no need to build or buy your own fraud shield, unlike other alternatives.
We provide the critical seller configuration controls to help you reduce the interchange fees, from the seller classification in front of the card networks to online verifications of the card input.
3/ With the point of sale (POS), we picked our processing capabilities to support both card-present (used in POS) and card not present (online) under our same master MOR. This enabled us to continue reducing our transaction costs since card-present are cheaper (lower risk than online) and provide a single solution to our sellers so that the payment lifecycle use cases could navigate among channels and be viewed holistically.
Our next major release in our payment roadmap is to expose our current card-present capabilities via SDKs to a suite of modern card readers supported in our platform.
4/ Payment equates to revenue; therefore, we architected a fault-tolerant stack to maintain 99.99+ availability levels at the API layer, including an elastic nature to scale with demand cost-effectively.
5/ We take care of regulatory compliances, such as PCI and PII, so that your implementation can be descoped thanks to a token-based architecture and secure storage infrastructures. The same goes for enterprise-grade uptime and reliability.
6/ Expand via our APIs
Our transactional API layer is tightly integrated into payments for common use cases such as order management, events, ticketing, membership, donations, scanning, and much more. All of these higher-level features can also help reduce your development lift by building off your core payment integration.
7/ Global footprint to pay out your sellers in their local currencies without expensive conversion fees
We support most significant markets to settle in their local currency, besides accepting presented payments in 180+ currencies. So you only need to code once to a single interface, versus usually a different one per country, to deploy in the markets where you are present or want to expand. This consolidation can help re-allocate your precious engineering resources to focusing on your core use cases.
Our mission
Our mission has always been to empower our clients’ growth via our transactional platform. After such a significant investment and working through the rigors of production over many years, we would like to extend this knowledge and platform to help you succeed in payments. We want to empower you to have greater ownership of the payment revenue, expand into POS, with the ability to control your transaction costs precisely, and more easily go global.
These new payment capabilities can be leveraged by our existing ticketing and membership application clients. It can help consolidate your payments under one platform to understand your constituent views better, upgrade them to members and leverage your existing integrations, including general ledgers.
To participate in our Beta program, please contact us and we will give you access to our API sandbox to pilot your trials.
Echeyde Cubillo
CTO/co-founder