Sviluppatori / API pubblica

API pubblica per integrazioni di pagamento sicure.

Usate VPOS.am come layer server-side per payment sessions, hosted checkout redirects, status verification e signed lifecycle events. Questa pagina documenta solo contratti merchant pubblici ed esclude console/admin API, provider credentials e operator workflows.

Scope pubblico

Documented

Merchant payment-session creation, payment status lookup, non-secret health status, webhooks and idempotent retries.

Not documented here

Console/admin endpoints, operator tokens, provider credentials, bank secrets, payout details and internal reconciliation controls.

Production access

Production credentials are issued only after merchant onboarding, domain review, callback verification and a test payment flow.

Do not call merchant endpoints from browser code or mobile apps with embedded secrets. Keep bearer tokens and webhook secrets only on trusted backend services.

Avvio rapido

The minimum integration has three server-side parts: create a payment session, redirect the buyer to hosted checkout, then confirm the final status through status lookup or a signed webhook.

curl -X POST https://api.vpos.am/v1/payment-sessions \
  -H "Authorization: Bearer <merchant_api_token>" \
  -H "Content-Type: application/json" \
  -H "Idempotency-Key: order-1001-pay-attempt-1" \
  -d '{
    "merchantOrderId": "order-1001",
    "amountMinor": 15000,
    "currency": "AMD",
    "provider": "manual",
    "returnUrl": "https://merchant.example/payments/return",
    "customer": {
      "email": "buyer@example.com",
      "phone": "+37400000000",
      "name": "Test Buyer"
    },
    "metadata": {
      "source": "custom-backend"
    }
  }'

The browser return URL is not proof of payment. Treat it as a user-interface event only. Fulfillment must wait for server-side verification or a signed webhook event.

Endpoints

GET /api/health

Returns non-secret runtime status for monitoring and integration checks. The response can include readiness blockers, but clients should not treat blocker text as a stable contract.

StatoSignificato
200Service is reachable. Readiness is reported in the JSON body.
405Unsupported HTTP method.
GET /v1/capabilities

Returns the conservative provider capability matrix. Use it to gate PayLink, QR, refund, fiscalization and tokenization UI before enabling merchant-facing actions.

CampoRegole
providers[].capabilitiesBoolean support/enabled flags per provider route.
payment_links, qr_presentationEnabled only when the selected route can create payment sessions.
refund, capture, void, tokenization, subscriptionsPublic contracts are guarded. Execution is available only when the provider capability is enabled; otherwise requests return explicit disabled/not-configured errors.
POST /v1/payment-links

Creates an idempotent payment link backed by a payment session. The QR payload is URL presentation only; final payment status still comes from webhook or reconciliation.

CampoRegole
Idempotency-KeyRequired header. Reuse it for retries to avoid duplicate payment links.
amount, currencyMajor-unit amount plus AMD/USD/EUR currency. AMD must be a whole number.
descriptionRequired customer-facing payment description.
expiresAtOptional future ISO date/time. Expiry does not prove payment outcome.
providerRouteOptional provider route. Unsupported or not-ready routes are rejected.
POST /v1/payment-sessions

Creates a normalized payment session and returns a hosted checkout URL when the selected provider can initiate checkout.

CampoRegole
merchantOrderIdRequired merchant-side order reference. Use a stable value for reconciliation.
amountMinorRequired integer amount in minor currency units.
currencySupported public values: AMD, USD, EUR.
returnUrlAbsolute HTTPS URL where the buyer returns after checkout.
customerOptional email, phone and name. Store only what your business process requires.
POST /v1/payments/{id}/refunds · /capture · /void

Guarded operation contracts for refunds, capture, void, fiscal retry, tokenization and subscriptions. They require Idempotency-Key. Enabled provider routes execute server-side and verify final provider status before changing the local payment state.

CampoRegole
Idempotency-KeyRequired for every money-moving or lifecycle operation.
refundRequires verified paid/partially_refunded payment, amountMinor, matching currency and reason.
capture, voidCapture requires authorized payment. Void/cancel requires a provider-eligible authorized or paid payment. Browser return is never used as proof.
tokenizationRaw card data is rejected; provider-hosted token lifecycle and consent are required.
subscriptionsRequire a provider token and failed-renewal behavior before execution can be enabled.
GET /v1/payments?paymentId=<id>

Returns the current normalized payment state for a previously created session.

StatoGestione consigliata
created, pending_*, authorizedDo not fulfill. Continue polling or wait for a webhook.
paidFulfillment may proceed after amount, currency and order reference are matched.
failed, cancelled, expiredShow failure state or create a new payment attempt.
refunded, partially_refunded, reversed, disputedSync accounting, CRM and customer support workflows.

Webhooks

Webhook delivery is configured per merchant during onboarding. Your endpoint should verify the HMAC signature, persist the event id, return quickly and process business side effects in a queue.

{
  "id": "evt_01hxxexample",
  "type": "payment.status_changed",
  "createdAt": "2026-05-25T08:00:00.000Z",
  "payment": {
    "id": "pay_01hxxexample",
    "merchantOrderId": "order-1001",
    "amountMinor": 15000,
    "currency": "AMD",
    "status": "paid"
  }
}

Signature header format: X-VPOS-Signature: sha256=<hex_hmac_sha256>. Compute HMAC over the raw request body with the merchant webhook secret.

Idempotency

Use Idempotency-Key for retryable operations such as payment-session creation. Store the key with the order and payment attempt in your system. A network retry must not create a second payable order or invoice.

  • Use a deterministic key per order payment attempt, not a random key for every retry.
  • Keep separate keys for separate user-initiated attempts.
  • Log the VPOS payment id, merchant order id, amount and currency together.

Errori

HTTP statusSignificatoAzione integratore
401Missing or invalid merchant bearer token.Do not retry blindly. Rotate or reissue credentials.
403Request origin is not trusted.Use server-to-server requests or register the backend origin.
422Validation failed.Fix request data before retrying.
429Rate limited.Back off and retry with jitter.
503Provider, storage or authentication dependency is not ready.Retry later or contact support if this blocks production.

Regole di sicurezza

  • Never expose merchant bearer tokens, webhook secrets or provider credentials in frontend code.
  • Use HTTPS only and verify server certificates in backend clients.
  • Accept a payment as final only after server-side status confirmation.
  • Validate amount, currency and merchant order id before changing order, CRM or ERP state.
  • Store webhook event ids and reject duplicate side effects.
  • Log failed signature checks and unexpected status transitions without storing unnecessary personal data.

This public page intentionally does not include production tokens, internal console routes, private provider callbacks, database details or bank credentials.

Richiesta accesso

For pilot or production access, send your company name, website, integration type, expected provider, currencies, callback URL and contact person to info@vpos.am.

Before production, VPOS.am reviews merchant identity, domain ownership, callback security, test payment results, refund and reconciliation process, and support ownership.