Developer preview API v1

Sandbox only. No real funds moved. No production access is granted here. Access requirements

Public client + PKCE

Authorize in the browser, exchange on your server

A public browser client uses PKCE while the server performs the token exchange and every authenticated payment call.

Recommended path

Use a browser public client with PKCE. The browser redirects to authorization, your server exchanges the authorization code, and the server then calls POST /v1/payments with the developer-app credential.

The browser never holds a token secret

PKCE binds the authorization code to your browser session, but the token and the developer-app credential stay on your server. Customer-visible JavaScript only calls your own server routes.

Prohibited

Do not embed a live credential in client-side JavaScript, ship a credential-shaped live key in a public bundle, or place a bearer secret in a browser request header. Do not invent token endpoints that are absent from the catalog; your server performs the exchange.

PKCE server-mediated flow

1. Browser generates a PKCE code_verifier and sends the code_challenge
2. Browser redirects to the authorization endpoint
3. Your server exchanges the authorization code (never the browser)
4. Your server calls POST /v1/payments with the developer-app credential
5. Browser receives only the result, never a bearer secret