Start  /  Dla deweloperów

Dla deweloperów

Najpierw przeczytaj dokumentację. Po to jest.

REST, JSON, token bearer. 3-D Secure zarządzane po stronie serwera, więc nigdy nie dotykasz CAVV. Jeśli cokolwiek tutaj wymaga telefonu, żeby to zrozumieć, to nasz błąd — nie Twoje niezrozumienie.

REST + JSON Uwierzytelnianie bearer 3DS po stronie serwera Sandbox z kartami testowymi

Dwa klucze API, dwie powierzchnie

Wybierz tę, która Cię opisuje, a nie tę, która brzmi poważniej

Merchant

Przetwarzasz płatności na własny rachunek.

  • Inicjowanie, capture, zwrot, void i sprawdzanie statusu
  • Weryfikacja 3-D Secure obsługiwana po stronie serwera
  • Bez identyfikatora akceptanta — Twój klucz jest kontem
Endpointy merchanta

Partner

Jesteś ISO z własną bramką i zarządzasz powiązanymi akceptantami.

  • Lista powiązanych akceptantów i odczyt ich transakcji
  • Inicjowanie w ich imieniu przez podanie identyfikatora akceptanta
  • Capture, zwrot i void pozostają wyłącznie po stronie merchanta
Endpointy partnera

Szybki start

Krócej, niż się spodziewasz

Jeden base URL, jeden nagłówek. Klucze API wydaje nasz zespół i przekazuje bezpiecznym kanałem — nie ma samoobsługowego generowania kluczy i nie będzie, dopóki nie da się tego zrobić bez osłabienia onboardingu.

# Sandbox
https://api.sandbox.bergopay.com/

Uwierzytelnianie zapytań

Każdy uwierzytelniony endpoint oczekuje tokenu bearer. To cała historia uwierzytelniania.

Authorization: Bearer {YOUR_AUTH_KEY}
Content-Type: application/json
Accept: application/json

Koperta odpowiedzi

Każda odpowiedź niesie te same cztery klucze, niezależnie od powodzenia. Sprawdzaj success, a przy wartości false czytaj code.

{
  "success": true,
  "message": "Transaction initiated",
  "code": "",
  "data": { ... }
}

Sprawdź swój klucz

GET /api/v1/key-info REQUIRES AUTH

Zwraca to, do czego uprawnia posiadany klucz. Przydatne pierwsze wywołanie, gdy coś zachowuje się nieoczekiwanie.

3-D Secure

Dziś nie będziesz obsługiwać CAVV

3DS jest zarządzane po stronie serwera. Nigdy nie budujesz ani nie przechowujesz CAVV, ECI czy DS Transaction ID — weryfikujesz, dostajesz id i przekazujesz id.

  • Krok 1 — wywołaj endpoint weryfikacji z danymi karty, kwotą, walutą i swoim URL powrotnym
  • Krok 2 — ścieżka frictionless zwraca od razu status: full_auth; challenge zwraca challenge_url
  • Krok 3 — po challenge posiadacz karty wraca na Twój URL z identyfikatorem weryfikacji i statusem
  • Krok 4 — zainicjuj transakcję z tym id w card_verification_data
POST /api/v1/3ds/verify REQUIRES AUTH
{
  "amount": 12.5,
  "currency": "EUR",
  "card": {
    "name": "John Doe",
    "number": "4200000000000091",
    "exp_month": "12",
    "exp_year": "2030",
    "cvv": "123"
  },
  "auth_url": "https://yoursite.com/checkout/3ds-complete"
}
// 200 — frictionless
{
  "success": true,
  "data": {
    "id": 166,
    "status": "full_auth",
    "auth_type": "frictionless",
    "version": "2.2.0",
    "eci": "05"
  }
}

Przenieś to id do transakcji, a zapisane dane uwierzytelnienia zostaną dołączone za Ciebie.

Endpointy merchanta

Pięć wywołań pokrywa cały cykl życia płatności kartą

Zainicjuj transakcję

POST /api/v1/transactions REQUIRES AUTH

sale obciąża od razu. auth zakłada blokadę i wymaga capture, żeby się rozliczyć. Wybieraj świadomie — różnica ujawnia się w profilu zwrotów i sporów miesiące później.

{
  "amount": 12.5,
  "currency": "EUR",
  "transaction_type": "sale",
  "card": {
    "number": "4111111111111111",
    "exp_month": "12",
    "exp_year": "2030",
    "cvv": "111",
    "name": "John Doe"
  },
  "reference": "order-10001",
  "success_url": "https://yoursite.com/checkout/success",
  "error_url": "https://yoursite.com/checkout/error",
  "customer": {
    "merchant_customer_id": "cust-001",
    "first_name": "John",
    "last_name": "Doe",
    "email": "john.doe@example.com",
    "country_code": "PL",
    "ip_address": "198.51.100.5"
  },
  "card_verification_data": { "id": 43 }
}

Użyj vault_token zamiast obiektu karty, żeby obciążyć zapisany instrument. reference to Twój numer zamówienia i wraca w każdym powiązanym rekordzie.

// 200
{
  "success": true,
  "message": "Transaction initiated",
  "data": {
    "id": 2,
    "amount": 1250,
    "currency": "EUR",
    "status": "auth",
    "transaction_type": "auth",
    "merchant_trans_id": "ORDER-912346",
    "acquirer_trans_id": "514009741995",
    "acquirer_auth_code": "400066"
  }
}

Capture

POST /api/v1/transactions/{id}/capture MERCHANT ONLY

Dotyczy wyłącznie transakcji typu auth. Podaj amount, żeby wykonać capture częściowy.

Zwrot

POST /api/v1/transactions/{id}/refund MERCHANT ONLY
{ "amount": 12.5, "reason": "Customer returned item" }

Void

POST /api/v1/transactions/{id}/void MERCHANT ONLY

Anuluje autoryzację, zanim się rozliczy. Taniej i czyściej niż zwrot po fakcie.

Status

GET /api/v1/transactions/{id}/status REQUIRES AUTH

Statusy zwracane przez API to m.in. auth, captured, refunded i voided. Klucze partnerskie mogą odczytywać status akceptantów, z którymi są powiązane.

Endpointy partnera

Masz już bramkę. Nie będziemy Ci wysyłać checkoutu.

Klucze partnerskie zarządzają powiązanymi akceptantami. Zachowujesz własny checkout, tokenizację i identyfikatory akceptantów; my siedzimy wyżej w łańcuchu. Jedna zasada warta zapamiętania od razu: capture, zwrot i void pozostają wyłącznie po stronie merchanta, nawet gdy klucz partnerski może odczytać status.

Lista powiązanych akceptantów

GET /api/v1/merchants PARTNER ONLY

Pobierz pojedynczego akceptanta

GET /api/v1/merchants/{merchant_id} PARTNER ONLY

Transakcje akceptanta

GET /api/v1/merchants/{merchant_id}/transactions PARTNER ONLY

Filtruj przez status, from, to i per_page. Maksymalny rozmiar strony to 100.

GET /api/v1/merchants/1/transactions
  ?status=success
  &from=2026-01-01
  &to=2026-12-31
  &per_page=25

Inicjowanie w imieniu akceptanta

Klucze partnerskie mogą wywoływać endpoint transakcji, ale muszą podać merchant_id akceptanta powiązanego z tym partnerem.

{
  "amount": 129.00,
  "currency": "EUR",
  "transaction_type": "sale",
  "merchant_id": 123,
  "card": { ... },
  "reference": "YOUR-ORDER-4471"
}

Kaskadowanie i ponowienia podlegają limitom opublikowanym na stronie bramki — nigdy jako obejście 3-D Secure, nigdy ponad limity ponowień organizacji kartowych.

Błędy

Błąd powinien mówić, co zrobić dalej

Niepowodzenia używają tej samej koperty, z maszynowo czytelnym code, a przy problemach walidacyjnych z obiektem errors per pole.

// 401
{
  "success": false,
  "message": "Authentication failed",
  "code": "ERR_AUTH_FAILED",
  "data": null
}
// 422
{
  "success": false,
  "message": "Validation errors",
  "code": "ERR_VALIDATION_FAILED",
  "data": null,
  "errors": {
    "amount": ["The transaction amount must be a number."]
  }
}

Rozgałęziaj logikę na code, nie na message. Komunikaty są pisane dla ludzi i mogą zostać przeredagowane.

Testowanie

Karty testowe na każdy zły dzień

Używaj ich na endpointcie weryfikacji 3DS. Testuj ścieżki nieudane — to właśnie one docierają do Twoich klientów.

Numer kartyOrganizacjaŚcieżkaOczekiwany wynik
4200000000000091VisaFrictionlessSUKCES
4200000000000109VisaFrictionlessPRÓBA
4200000000000042VisaChallengeCHALLENGE
4012001037461114VisaBłądBŁĄD TECHNICZNY
4012001037141112VisaBłądBRAK REJESTRACJI
4532497088771651VisaNie dotyczyNIE UCZESTNICZY
5200000000000007MastercardFrictionlessSUKCES
5200000000000023MastercardFrictionlessPRÓBA
5200000000000015MastercardChallengeCHALLENGE
5434580000000006MastercardBłądBŁĄD TECHNICZNY
5457350076543210MastercardBłądBRAK REJESTRACJI
5497260847316287MastercardNie dotyczyNIE UCZESTNICZY

Pełny zestaw obejmuje dalsze warianty frictionless i challenge, uwzględniające zwracanie danych metody. Napisz, a wyślemy kompletną listę razem z kluczem do sandboxa.

Klucze wydajemy my, nie generujesz ich sam. Dane do sandboxa przekazujemy bezpiecznym kanałem po rozpoczęciu onboardingu, żebyś mógł budować, gdy formalności biegną równolegle. Dane produkcyjne następują po zakończonej weryfikacji onboardingowej.

Zacznij

Najpierw rozłóż to w sandboxie.

Powiedz, na której ścieżce jesteś i co budujesz. Dostaniesz dane do sandboxa, pełną dokumentację i inżyniera, który odpowiada, zamiast formularza, który potwierdza odbiór.