canonical: https://jentic.com/apis/mobeco.dk/mobeco

# Mobeco Dk MobilePay API

Jentic publishes the only available OpenAPI specification for MobilePay API, keeping it validated and agent-ready. The MobilePay API hosted at api.mobeco.dk exposes mobile payment endpoints for the Danish MobilePay product. The three endpoints cover creating a new payment, fetching the current status of a specific payment by ID, and issuing a refund. Authentication uses an API key passed in the Authorization header.

## For AI agents

Initiate MobilePay mobile payments in Denmark, retrieve payment status, and issue refunds through three API key-authenticated endpoints.

## Scope

Does not handle card payments, subscription billing, or non-Danish wallets - use for MobilePay payment creation, status lookup, and refunds in Denmark only.

## Capabilities

- Initiate a MobilePay payment for a Danish customer
- Retrieve the status of a specific payment by its ID
- Issue a refund against a completed MobilePay payment

## Use cases

### E-Commerce Checkout in Denmark

A Danish e-commerce checkout offers MobilePay alongside card payments because of its dominance in the Danish consumer market. The merchant creates a payment via POST /payments with the order amount and customer reference, then redirects the user to confirm in the MobilePay app. After confirmation the merchant polls the payment status endpoint to release the order for fulfilment.

Example prompt: Create a payment for 249.00 DKK via POST /payments, capture the returned payment ID, and poll GET `/payments/{id}` until status is completed

### Order Refund Workflow

When a Danish customer returns a purchase, customer service issues a refund through the refunds endpoint referencing the original payment ID and the refund amount. Partial refunds for partial returns are supported. The refunded amount is returned to the customer's MobilePay app and reconciled against the original transaction in the merchant ledger.

Example prompt: Issue a refund for the original payment by calling POST /refunds with the payment ID and refund amount in DKK

### Payment Status Reconciliation

A finance team reconciles MobilePay payments against orders by polling the GET `/payments/{id}` endpoint for any orders that have not received a webhook confirmation. The structured status response - pending, completed, cancelled, failed - drives the reconciliation script to release, retry, or mark the order as unpaid.

Example prompt: For each unconfirmed order ID, call GET `/payments/{id}` and update the order status based on the returned payment state

### Agent-Driven Payment Flow

An agent discovered through Jentic creates the MobilePay payment, monitors its status, and triggers refunds when ordered. Jentic stores the API key in its credential vault so the agent only invokes the create, lookup, and refund operations rather than holding the raw Authorization header value in its runtime.

Example prompt: Use Jentic to find the MobilePay create payment operation and execute it with order amount 199.00 DKK and customer reference {orderId}

## Key endpoints

| Method | Path | Description |
| --- | --- | --- |
| POST | `/payments` | Create a new MobilePay payment |
| GET | `/payments/{id}` | Retrieve a payment by ID |
| POST | `/refunds` | Issue a refund against a payment |

## Key resources

- **Payments** — Create payments and look up status by ID
- **Refunds** — Issue full or partial refunds against completed payments

## Why Jentic

- **Setup:** Wiring this MobilePay API by hand means handling its API key auth, coding the Danish payment create and status lookup flow, and reconciling refunds yourself. Through Jentic you install once, import the MobilePay API from the API Directory, store the key once, and your agent calls it.
- **Permission scoping:** This MobilePay API puts the payment id in the URL path (`/payments/{id}`), so a rule can pin your agent to reading one payment: it can create a payment and check its status. You choose the operations it may call, so issuing refunds is not included unless you add it.
- **Credential handling:** Your MobilePay API key is stored once, encrypted, by your own Jentic One instance and injected at execution time. It never enters the agent's prompt, logs, or context.
- **Discovery method:** Agents search Jentic by intent such as 'create a MobilePay payment' or 'check a payment's status', and Jentic returns the matching MobilePay operation with its input schema so the agent calls the right endpoint without browsing the reference docs.

## Related APIs

- **MobilePay (mobilepay.dk) API** — Alternative MobilePay API surface in the corpus
- **Stripe API** — Global card and wallet payments platform
- **Mollie API** — European payments aggregator with multiple local methods

## FAQ

### Why is there no official OpenAPI spec for MobilePay API?

Mobeco does not publish an OpenAPI specification. Jentic generates and maintains this spec so that AI agents and developers can call MobilePay 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 MobilePay API use?

The API uses an API key passed in the Authorization header. Generate the key from the Mobeco merchant portal and include it on every request. Through Jentic the key is stored in the credential vault and injected at execution time so agent code never sees the raw value.

### Can I issue partial refunds with the MobilePay API?

Yes. POST /refunds takes the original payment ID and a refund amount that may be smaller than the original charge. The refund is returned to the customer's MobilePay account and reconciled against the original payment.

### What are the rate limits for the MobilePay API?

Mobeco applies per-merchant rate limits on payment creation and refund issuance to protect against abuse. Status lookups have higher quotas than write calls. Coordinate with Mobeco support for current numeric limits before high-volume promotions.

### How do I create a payment through Jentic?

Search Jentic for create mobilepay payment, load the schema for POST /payments, and execute with the order amount in DKK and a merchant order reference. The response includes the payment ID and a status to poll.

### Does the MobilePay API cover other Nordic countries?

This API surface targets the Danish MobilePay product. For Norwegian, Finnish, or other Nordic mobile-payment products, use the country-specific API for that market rather than the Mobeco endpoints.

### Can I limit what my agent is allowed to do with the MobilePay API?

Yes. Because you run Jentic One yourself, your own rules decide which of the MobilePay operations the agent may call, so you can let it create a payment (POST /payments) and check status (GET `/payments/{id}`) while leaving refunds (POST /refunds) out unless you add them. Since the payment ID sits in the URL path, a rule can also pin the agent to reading a single payment rather than any status lookup. Your API key is held by your own instance and injected at execution time, so the agent only invokes the operations you permit and never handles the raw Authorization value.
