Developers
Payments you can integrate in days.
A modern REST API, a sandbox to build against, and clear documentation with working examples. Integrate online payments, recurring billing and in-person terminals — all behind one developer portal.
POST /api/v3/transaction/{apiKey}/debit { "merchantTransactionId": "order-1001", "amount": "49.00", "currency": "CHF", "transactionToken": "tok_from_javascript", "callbackUrl": "https://yourapp.com/callback" }
Developer portal
Everything you need, in one place.
The developer portal is the single home for building on Juno — documentation, integration guides, sandbox access and credentials. Start there, and move from first call to production without hunting for what you need.
Documentation
API reference & guides
Sandbox keys
Test credentials
Integration guides
From first call to live
The APIs
Two APIs. Every way you take payment.
Online & recurring
Card payments, tokenisation and subscriptions
A REST/JSON API for online and card-not-present payments — tokenise cards, take one-off or recurring charges, pre-authorise and capture, refund and pay out. 3-D Secure 2 and fraud tooling are handled for you.
Gateway API docs→In-person
Drive physical terminals from your PMS or POS
Connect your property-management or point-of-sale system to payment terminals — initiate payments, pre-authorisations and refunds on the device, straight from your application.
Terminal Connect docs→Fast to build
Built to get you to production quickly.
Modern REST/JSON
A clean V3 REST API with predictable requests, structured responses and documented error codes — so your error handling is reliable, not guesswork.
Integrate your way
Four integration flows — hosted page, embedded iframe, drop-in JavaScript, or server-to-server — so you choose control versus speed to fit your stack.
Low PCI scope
Collect card data through our JavaScript library and the sensitive fields render in our PCI-compliant iframes — keeping your PCI-DSS scope to SAQ-A.
Sandbox first
Build and test against a sandbox before you go live. Real flows, no real money.
Secure by default
3-D Secure 2, signed callbacks (HMAC-SHA512) and optional fraud screening are part of the platform — not extra projects.
Clear examples
Documentation with working request and response samples for every flow, so you're not reverse-engineering the API.
Integration flows
Choose control or speed — or both.
Hosted payment page
The fastest path. Redirect to a ready-made payment page; nothing sensitive touches your servers.
Embedded form (iframe)
Keep guests on your page with an embedded payment form.
Drop-in JavaScript
Collect and tokenise card data inside your own checkout for a seamless, branded experience, with PCI scope kept to SAQ-A.
Server-to-server
Full control for recurring charges, refunds, captures, voids and alternative methods — no front-end required.
Hosted payment page
The fastest path. Redirect to a ready-made payment page; nothing sensitive touches your servers.
Embedded form (iframe)
Keep guests on your page with an embedded payment form.
Drop-in JavaScript
Collect and tokenise card data inside your own checkout for a seamless, branded experience, with PCI scope kept to SAQ-A.
Server-to-server
Full control for recurring charges, refunds, captures, voids and alternative methods — no front-end required.
Quick start
From token to payment in one call.
Tokenise the card in the browser, then send the transaction from your backend. A debit looks like this — the docs cover every field, flow and response.
This snippet is an illustrative teaser — the authoritative detail lives in the linked docs.
POST /api/v3/transaction/{apiKey}/debit { "merchantTransactionId": "order-1001", "amount": "49.00", "currency": "CHF", "transactionToken": "tok_from_javascript", "callbackUrl": "https://yourapp.com/callback" }
Built-in capabilities
The hard parts, already handled.
Full transaction lifecycle
Debit, pre-authorise, capture, void, refund and payout — the operations hospitality actually needs.
Card-on-file & recurring
Store a card once and charge it again — with a scheduler for automated recurring billing.
3-D Secure 2
Frictionless and challenge flows handled, with the redirects managed for you.
Fraud & risk
Optional screening integrations so risk checks plug in without custom work.
Built for AI agents
Built for Claude Code and any AI agent.
Juno's integration contracts don't just expose endpoints — they describe complete hospitality payment workflows. Point an AI agent at them and it can build a full PMS integration, Pay-by-Link journey, card-on-file flow or reconciliation process. Not just call an API — build the integration.
// Juno integration contract — pre-auth lifecycle workflow: "preauthorization" steps: - preauthorize → reserve funds at check-in - topUp → incremental authorization during stay - capture → complete on checkout - settle → payout + reconciliation rules: - capture within authorization window - idempotencyKey required on every step - amounts in minor units, currency per account
Illustrative excerpt — the full contracts describe every workflow, rule and business constraint.
APIs describe endpoints. Contracts describe what to build.
Most APIs tell a developer what endpoints exist. Juno's contracts tell an AI agent what to build — the workflows, the lifecycle rules and the constraints — so it ships a working integration, not a pile of disconnected calls.
Agent-built workflows
What an AI agent can build with Juno.
Build PMS integrations
Connect property-management systems to payments end to end.
Build payment workflows
Pre-auth, capture, refund and payout flows that respect the rules.
Build Pay-by-Link journeys
Generate links, take the guest payment, update the PMS.
Build card-on-file flows
Tokenise once, charge later, stay PCI-aware.
Build reconciliation processes
Match transactions to settlements automatically.
Build hotel onboarding automation
Stand up new properties without manual setup.
Build settlement integrations
Move settled data into ERP and finance systems.
Each one is described as a contract an agent can read and implement — not a scavenger hunt across reference pages.
Workflow intelligence
Whole lifecycles, not isolated calls.
Juno contracts describe complete hospitality payment lifecycles. An agent reads the flow and builds it end to end — every step in order, every rule respected.
The contract carries the order, the timing rules and the business constraints — so the workflow an agent builds is the workflow that actually runs in production.
Guardrails
The AI doesn't need to guess.
Autonomous development needs guardrails. Every Juno contract ships with what an agent needs to build correctly the first time — so there's no guessing, no hallucinated fields, no missing step.
Complete endpoint coverage
Nothing the workflow needs is left undocumented.
Request/response schemas
Exact shapes, in and out.
Authentication standards
How to sign and authorise every call.
Idempotency controls
Safe retries, no double charges.
Security requirements
What must be enforced, and where.
PCI-aware patterns
Handle card data the compliant way by default.
Error handling guidance
Documented codes and what to do about them.
Lifecycle examples
Worked, end-to-end flows to build against.
Why this is different
Not documentation. A blueprint to build from.
- Tell you what endpoints exist
- Leave the workflow for you to assemble
- Assume a human will fill the gaps
Juno integration contracts
- Tell an agent what to build
- Describe how the workflows operate
- Specify which lifecycle rules must be respected
- Specify which business constraints apply
That's the difference between calling an API and building an integration.
Built on the same production APIs and contracts powering active payment locations across the Juno platform.
Integration teams ship on Oracle, SIHOT and major PSPs against these contracts.
Designed for Claude Code, Cursor, Windsurf and GitHub Copilot workflows.
Start building.
Get sandbox keys, read the docs, and ship your first payment — or talk to our integration engineers about your project.
Knowledge
Juno Developer Platform — questions answered
Quick facts
- API
- REST / JSON v3, versioned and stable.
- Integration flows
- Hosted payment page, iframe, drop-in JavaScript and server-to-server (S2S).
- PCI scope
- SAQ-A is available through hosted, iframe and drop-in flows; S2S carries the fuller obligation.
- Security
- HMAC-SHA512 callback signing with replay protection; 3-D Secure 2 with frictionless and challenge flows.
Frequently asked questions
What is the Juno developer platform?
The Juno developer platform is the API surface that developers integrate against to accept, orchestrate and reconcile payments on Juno. It exposes a versioned REST / JSON v3 API and four integration flows — hosted payment page, iframe, drop-in JavaScript and server-to-server — so an integrating team can pick the shape that matches its PCI posture, its user experience requirements and the platform it is integrating from. The same API also drives the PMS, POS and ERP integrations that ship on Juno.
Related: Integrations, Payment integration
How do I get sandbox access?
Sandbox access is provisioned through the 934 team. The sandbox is a fully separate environment — no real cards, no real money — that mirrors production for authorisation, capture, refunds, callbacks and 3-D Secure 2, so a developer can build against realistic responses before any production credentials are issued. Contact 934 through the developer contact route to request an environment.
Related: Contact 934
Which integration flow should I choose?
Choose the integration flow that matches your PCI posture and user experience. Hosted redirect keeps PCI scope at SAQ-A and is quickest to ship. Iframe keeps PCI scope at SAQ-A while retaining brand control of the surrounding page. Drop-in JavaScript embeds a Juno-hosted payment element inline and remains SAQ-A. Server-to-server (S2S) gives the fullest control but takes on the broader PCI obligation because your servers handle card data. Most hospitality integrations sit on hosted, iframe or drop-in.
Related: Payment integration
What is the PCI scope with Juno?
For hosted, iframe and drop-in flows, PCI scope is generally SAQ-A because card data is entered directly into a Juno-hosted surface and is never handled by the integrating merchant's systems. Server-to-server flows carry a broader obligation because the merchant's servers touch card data. This is aligned with card scheme guidance rather than a Juno-specific rule, and applies to the acceptance channels the merchant chooses.
Related: Payment orchestration
How are callbacks secured?
Callbacks from Juno to the integrating server are signed with HMAC-SHA512 and include replay protection, so a receiver can verify that a callback originated from Juno and that it has not been replayed. The signing secret is issued per integration. Receivers should verify the signature and timestamp before acting on any callback payload.
Does Juno support 3-D Secure 2?
Yes. Juno supports 3-D Secure 2 across the integration flows, with both frictionless authentication — where the issuer authenticates the cardholder in the background without additional input — and challenge flows, where the issuer requires an additional step. The choice is driven by the issuer and the transaction, not by the merchant, and Juno orchestrates the correct handling from acceptance through to authorisation.
Related: Payment integration