Skip to main content
Orchestra’s JavaScript Payments Library and REST API are complementary parts of one integration, not alternative ways to do the same job. Most implementations use both: the Library to capture payment in the customer’s frontend, the REST API to drive backend operations afterward. Both give you automatic gateway failover and access to payment providers.

​
Who does what

​
Use the Library to:

  • Capture cards, Google Pay, Apple Pay, PayPal, UPI, and other APMs in your frontend
  • Keep cardholder data off your servers
  • Get pre-built UI and 3D Secure handling
  • Produce a token you then operate on through the REST API
Get started with the Library →

​
Use the API to:

  • Charge a token the Library captured
  • Authorize, capture, refund, or void a transaction
  • Run recurring or subscription billing against a stored token
  • Check transaction status and pull reporting data
Get started with the REST API →

​
Can the API accept raw card details?

The charge endpoint’s schema does accept raw card fields (card.cardNumber and cvv can be literal values instead of an @TOKEN reference). This exists for backends that already lawfully hold card data. It is not the standard integration path: sending raw card details through your own systems means cardholder data passes through them, which puts you in PCI DSS scope. The intended pattern is that the Payments Library captures the card and produces a token, and the REST API charges that token by passing it as an @TOKEN reference in the cardNumber field. Nobody integrates the REST API as their card-capture path.

Library Setup

Full Payments Library integration

Charge Payments (REST)

REST API charge implementation

Quickstart

Get started in 5 minutes

Complete Example

Full working code sample