canonical: https://jentic.com/apis/oppwa.com/oppwa-payment-api

# Oppwa HyperPay Open Payment Platform API

Jentic publishes the only available OpenAPI specification for HyperPay Open Payment Platform API, keeping it validated and agent-ready. The HyperPay Open Payment Platform (OPP) provides a server-to-server payment integration covering credit and debit cards, digital wallets, bank transfers, and a long list of alternative payment methods popular across the Middle East and Europe. Agents can prepare a checkout, run a server-to-server payment, look up payment status, and run back-office operations such as capture, reversal, refund, and rebill. Authentication is a bearer access token issued by the HyperPay merchant backend.

## For AI agents

Prepare checkouts, run server-to-server payments, and execute capture, reversal, refund, or rebill back-office operations on HyperPay's Open Payment Platform.

## Scope

Does not handle merchant onboarding, dispute case management, or settlement reporting - use for HyperPay payment processing and back-office payment operations only.

## Capabilities

- Prepare a hosted checkout session and receive a checkout ID for the payment widget
- Run a server-to-server payment with stored card credentials or registration tokens
- Look up the status of a payment after the customer completes checkout
- Capture a previously authorised payment to settle the funds
- Reverse, refund, or rebill an existing payment by referencing its payment ID

## Use cases

### Hosted-checkout payment flow

Merchants embedding HyperPay's hosted widget call POST `/v1/checkouts` to prepare a session, then redirect the shopper to the widget keyed by checkoutId. After the shopper submits, the merchant agent calls GET `/v1/checkouts/{checkoutId}/payment` to read the result and reconcile the order. This pattern offloads PCI scope to HyperPay while keeping the merchant in control of order state.

Example prompt: POST `/v1/checkouts` with amount=49.99, currency=EUR, paymentType=DB, then poll GET `/v1/checkouts/{checkoutId}/payment` until a final result code is returned.

### Subscription rebilling with registration tokens

SaaS merchants storing HyperPay registration tokens can run recurring charges entirely server-to-server through POST `/v1/payments` referencing the token. When a renewal date arrives, the agent calls `/v1/payments` with paymentType=DB and the registration ID, then checks the response to drive subscription state in the merchant's own database.

Example prompt: POST `/v1/payments` with the stored registration ID, paymentType=DB, amount, and currency to rebill the customer for the next subscription cycle.

### Refunds and reversals

Customer-support agents handling chargebacks and goodwill refunds use POST `/v1/payments/{paymentId}` with paymentType=RF (refund) or RV (reversal) to reverse the original capture without leaving the support workflow. This is the same back-office endpoint that handles capture and rebill, switched by the paymentType field.

Example prompt: POST `/v1/payments/{paymentId}` with paymentType=RF and the partial refund amount, then read the response result code to confirm success.

### AI agent for merchant operations

Through Jentic, an AI agent can resolve a support ticket like 'refund order 12345' by looking up the HyperPay payment ID in the order system and calling POST `/v1/payments/{paymentId}` with paymentType=RF. The HyperPay bearer token sits in your Jentic One instance, and the agent never sees the raw secret.

Example prompt: Search Jentic for 'refund a hyperpay payment', load POST `/v1/payments/{paymentId}`, and execute it with paymentType=RF and the payment ID from the support ticket.

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/v1/checkouts` | Prepare a hosted checkout session |
| GET | `/v1/checkouts/{checkoutId}/payment` | Read the result of a checkout |
| POST | `/v1/payments` | Run a server-to-server payment |
| GET | `/v1/payments/{paymentId}` | Get the status of a payment |
| POST | `/v1/payments/{paymentId}` | Run capture, reversal, refund, or rebill on an existing payment |

## Key resources

- **Checkouts** — Prepare a hosted checkout session and read its result
- **Payments** — Server-to-server payments and back-office operations (capture, reversal, refund, rebill)

## Why Jentic

- **Setup:** Wiring the HyperPay Open Payment Platform API by hand means sending its bearer token on every call and choosing the right EU test or EU prod host so you do not process a live payment against the sandbox. Through Jentic you install once, import the HyperPay API from the API Directory, store the token once, and your agent calls it.
- **Permission scoping:** HyperPay puts the payment id in the URL path (`/v1/payments/{paymentId}`), so a rule can pin your agent to reading the status of one payment. You choose the operations it may call, so submitting a new payment or capturing against an existing one is not included unless you add it.
- **Credential handling:** Your HyperPay bearer token is stored once, encrypted, by your own Jentic One instance and injected as the Authorization header at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'prepare a hyperpay checkout' or 'check a payment status', and Jentic returns the matching operation under `/v1/checkouts` or `/v1/payments` with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **Stripe** — Globally available payment processor with broad SDK and method coverage
- **Adyen Checkout** — Enterprise checkout API with worldwide coverage and unified reporting
- **Braintree** — PayPal-owned payment gateway with strong subscription tooling
- **Mollie** — European-focused PSP with strong local payment method coverage

## FAQ

### Why is there no official OpenAPI spec for HyperPay Open Payment Platform API?

HyperPay does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call HyperPay Open Payment Platform API via structured tooling. It is validated against the live API and kept up to date. Get started with Jentic One, the self-hosted execution layer.

### What authentication does the HyperPay OPP API use?

Each request is authorised with an HTTP bearer access token issued by the HyperPay merchant backend. Through Jentic the token is stored encrypted in the vault and added to the Authorization header at execution, so the agent never receives the secret.

### Can I issue a refund through this API?

Yes. Refunds are issued by POST `/v1/payments/{paymentId}` with paymentType=RF. The same endpoint handles capture (CP), reversal (RV), and rebill (DB) - the operation is selected by the paymentType field rather than separate URLs.

### What are the rate limits for the HyperPay OPP API?

HyperPay does not document rate limits in this spec; they are governed by the merchant's contract and the test or production environment in use. The spec exposes both eu-test.oppwa.com and eu-prod.oppwa.com servers, and limits are stricter on the test environment.

### How do I prepare a checkout through Jentic?

Search Jentic for 'prepare a hyperpay checkout', load POST `/v1/checkouts`, and execute it with amount, currency, and paymentType. The response includes a checkoutId you pass to the HyperPay widget on the front end.

### Does this API handle 3D Secure?

3D Secure is enabled at the HyperPay account level and is signalled in the result codes returned by GET `/v1/payments/{paymentId}` and the checkout result endpoint. The agent inspects the result code to determine whether the payment succeeded, was rejected, or requires further action.

### Can I limit what my agent is allowed to do with the HyperPay Open Payment Platform API?

Yes. Because Jentic One is self-hosted, you set the rules that decide which HyperPay operations and credentials your agent may use. HyperPay puts the payment ID in the URL path (`/v1/payments/{paymentId}`), so you can pin the agent to reading the status of a single payment while excluding operations you have not authorised. Submitting a new payment through POST `/v1/payments` or capturing, reversing, or refunding an existing one stays off limits unless you explicitly allow it.