Skip to content

Do testowania

Skorzystaj z tych zasobów, aby przetestować integrację w różnych scenariuszach.

Poświadczenia testowe

Skonsultuj się ze swoim Opiekunem, aby rozpocząć proces wdrażania.

Po zakończeniu tego procesu otrzymasz dane uwierzytelniające do testów:

  • Kod terminala
  • Token okaziciela
  • Identyfikator Klienta (Client ID)

Po uzyskaniu tych danych, można rozpocząć proces integracji.

W środowisku testowym możesz:

  • Cyfrowo wdrażać sprzedawców, jeśli jesteś pośrednikiem płatności
  • Rozpocząć proces integracji
  • Poznać dostępne funkcjonalności i narzędzia
  • Przeprowadzać płatności testowe

Pamiętaj, że konto testowe pozwala na zapoznanie się z integracjami SIBS, ale nie gwarantuje przetwarzania płatności na żywo.

Karty testowe

Przed wdrożeniem przetwarzania płatności na żywo masz możliwość skorzystania z podanych danych karty na tej stronie w celach testowych.

Należy pamiętać, że dane te mają zastosowanie wyłącznie na naszej platformie testowej i nie obejmują rzeczywistych transakcji ani transferu jakichkolwiek środków.

Oto kilka kart testowych, których możesz użyć:

MarkaNumer kartyData wygaśnięciaCVC/CVV3DSHasło uwierzytelniania 3DS
Visa417666000000010012/25597Tak (Wyzwanie)123456
Visa476134000000003512/25536Nie
Mastercard518552005000001012/25001Tak (Wyzwanie)123456
Mastercard520474000000100212/25100Tak (bez tarcia)
Mastercard520636100000135112/25536Nie
Cartes Bancaires Visa4970 4178 0960 982303/23914Tak (bez tarcia)
Cartes Bancaires MasterCard5134 1486 5519 781704/24419Tak (Wyzwanie)123456
Cartes Bancaires Visa4010 0562 0000 001801/25123Tak (bez tarcia)
Cartes Bancaires MasterCard5137 2100 0000 001801/25123Tak (Wyzwanie)123456

Obsługa odpowiedzi

Kody odpowiedzi zapewniają cenny wgląd w wynik żądania API (FULL CODE) Ta strona zawiera kompleksowy opis potencjalnych kodów odpowiedzi, które można napotkać.

Kody statusu HTTP

Protokół HTTP definiuje zestaw czterdziestu standardowych kodów stanu, które komunikują wyniki żądania klienta. Te kody stanu są podzielone na pięć następujących grup:

KategoriaOpisSzczegóły
1xxInformacjePrzekazuje informacje na poziomie protokołu transferu.
2xxSukcesWskazuje, że żądanie klienta zostało pomyślnie zaakceptowane.
3xxPrzekierowanieWskazuje, że klient musi podjąć dodatkowe działania w celu ukończenia żądania.
4xxBłąd KlientaTa kategoria kodów statusu błędu wskazuje palcem na klientów.
5xxBłąd serweraSerwer bierze odpowiedzialność za te kody statusu błędu.
CodeDescriptionDetail and Action
200OKIt indicates that the REST API successfully carried out whatever action the client requested and that no more specific code in the 2xx series is appropriate.
Unlike the 204 status code, a 200 response should include a response body.The information returned with the response is dependent on the method used in the request, for example:
GET an entity corresponding to the requested resource is sent in the response;
HEAD the entity-header fields corresponding to the requested resource are sent in the response without any message-body;
POST an entity describing or containing the result of the action;
TRACE an entity containing the request message as received by the end server.
201CreatedA REST API responds with the 201 status code whenever a resource is created inside a collection. There may also be times when a new resource is created as a result of some controller action, in which case 201 would also be an appropriate response.
The newly created resource can be referenced by the URI(s) returned in the entity of the response, with the most specific URI for the resource given by a Location header field.
The origin server MUST create the resource before returning the 201 status code. If the action cannot be carried out immediately, the server SHOULD respond with a 202 (Accepted) response instead.
202AcceptedA 202 response is typically used for actions that take a long while to process. It indicates that the request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon, or even maybe disallowed when processing occurs.
Its purpose is to allow a server to accept a request for some other process (perhaps a batch-oriented process that is only run once per day) without requiring that the user agent’s connection to the server persist until the process is completed.
The entity returned with this response SHOULD include an indication of the request’s current status and either a pointer to a status monitor (job queue location) or some estimate of when the user can expect the request to be fulfilled.
204No ContentThe 204 status code is usually sent out in response to a PUT, POST, or DELETE request when the REST API declines to send back any status message or representation in the response message’s body.
An API may also send 204 in conjunction with a GET request to indicate that the requested resource exists, but has no state representation to include in the body.
If the client is a user agent, it SHOULD NOT change its document view from that which caused the request to be sent. This response is primarily intended to allow input for actions to take place without causing a change to the user agent’s active document view, although any new or updated metainformation SHOULD be applied to the document currently in the user agent’s active view.
The 204 response MUST NOT include a message-body and thus is always terminated by the first empty line after the header fields
205Reset ContentThe server successfully processed the request, asks that the requester reset its document view, and is not returning any content.
206Partial ContentThe server is delivering only part of the resource (byte serving) due to a range header sent by the client. The range header is used by HTTP clients to enable resuming of interrupted downloads, or split a download into multiple simultaneous streams.
300Multiple ChoicesIndicates multiple options for the resource from which the client may choose (via agent-driven content negotiation). For example, this code could be used to present multiple video format options, to list files with different filename extensions, or to suggest word-sense disambiguation.
301Moved PermanentlyThe 301 status code indicates that the REST API’s resource model has been significantly redesigned, and a new permanent URI has been assigned to the client’s requested resource. The REST API should specify the new URI in the response’s Location header, and all future requests should be directed to the given URI.
You will hardly use this response code in your API as you can always use the API versioning for new API while retaining the old one.
302FoundThe HTTP response status code 302 Found is a common way of performing URL redirection. An HTTP response with this status code will additionally provide a URL in the Location header field. The user agent (e.g., a web browser) is invited by a response with this code to make a second. Otherwise identical, request to the new URL specified in the location field.
Many web browsers implemented this code in a manner that violated this standard, changing the request type of the new request to GET, regardless of the type employed in the original request (e.g., POST). RFC 1945 and RFC 2068 specify that the client is not allowed to change the method on the redirected request. The status codes 303 and 307 have been added for servers that wish to make unambiguously clear which kind of reaction is expected of the client.
303See OtherA 303 response indicates that a controller resource has finished its work, but instead of sending a potentially unwanted response body, it sends the client the URI of a response resource. The response can be the URI of the temporary status message, or the URI to some already existing, more permanent, resource.
Generally speaking, the 303 status code allows a REST API to send a reference to a resource without forcing the client to download its state. Instead, the client may send a GET request to the value of the Location header.
The 303 response MUST NOT be cached, but the response to the second (redirected) request might be cacheable.
304Not ModifiedThis status code is similar to 204 (“No Content”) in that the response body must be empty. The critical distinction is that 204 is used when there is nothing to send in the body, whereas 304 is used when the resource has not been modified since the version specified by the request headers If-Modified-Since or If-None-Match.
In such a case, there is no need to retransmit the resource since the client still has a previously-downloaded copy.
Using this saves bandwidth and reprocessing on both the server and client, as only the header data must be sent and received in comparison to the entirety of the page being re-processed by the server, then sent again using more bandwidth of the server and client.
307Temporary RedirectA 307 response indicates that the REST API is not going to process the client’s request. Instead, the client should resubmit the request to the URI specified by the response message’s Location header. However, future requests should still use the original URI.
A REST API can use this status code to assign a temporary URI to the client’s requested resource. For example, a 307 response can be used to shift a client request over to another host.
The temporary URI SHOULD be given by the Location field in the response. Unless the request method was HEAD, the entity of the response SHOULD contain a short hypertext note with a hyperlink to the new URI(s). If the 307 status code is received in response to a request other than GET or HEAD, the user agent MUST NOT automatically redirect the request unless it can be confirmed by the user, since this might change the conditions under which the request was issued.
400Bad Request400 is the generic client-side error status, used when no other 4xx error code is appropriate. Errors can be like malformed request syntax, invalid request message parameters, or deceptive request routing etc.
The client SHOULD NOT repeat the request without modifications.
401UnauthorizedA 401 error response indicates that the client tried to operate on a protected resource without providing the proper authorization. It may have provided the wrong credentials or none at all. The response must include a WWW-Authenticate header field containing a challenge applicable to the requested resource.
The client MAY repeat the request with a suitable Authorization header field. If the request already included Authorization credentials, then the 401 response indicates that authorization has been refused for those credentials. If the 401 response contains the same challenge as the prior response, and the user agent has already attempted authentication at least once, then the user SHOULD be presented the entity that was given in the response, since that entity might include relevant diagnostic information.
402Payment RequiredReserved for future use. The original intention was that this code might be used as part of some form of digital cash or micropayment scheme, as proposed, and this code is not widely used.
403ForbiddenA 403 error response indicates that the client’s request is formed correctly, but the REST API refuses to honor it, i.e. the user does not have the necessary permissions for the resource. A 403 response is not a case of insufficient client credentials; that would be 401 (“Unauthorized”).
Authentication will not help, and the request SHOULD NOT be repeated. Unlike a 401 Unauthorized response, authenticating will make no difference.
404Not FoundThe 404 error status code indicates that the REST API can’t map the client’s URI to a resource but may be available in the future. Subsequent requests by the client are permissible.
No indication is given of whether the condition is temporary or permanent. The 410 (Gone) status code SHOULD be used if the server knows, through some internally configurable mechanism, that an old resource is permanently unavailable and has no forwarding address. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
405Method Not AllowedThe API responds with a 405 error to indicate that the client tried to use an HTTP method that the resource does not allow. For instance, a read-only resource could support only GET and HEAD, while a controller resource might allow GET and POST, but not PUT or DELETE.
406Not AcceptableThe 406 error response indicates that the API is not able to generate any of the client’s preferred media types, as indicated by the Accept request header. For example, a client request for data formatted as application/xml will receive a 406 response if the API is only willing to format data as application/json.
If the response could be unacceptable, a user agent SHOULD temporarily stop receipt of more data and query the user for a decision on further actions.
407Proxy Authentication RequiredThe client must first authenticate itself with the proxy.
408Request TimeoutThe server timed out waiting for the request. According to HTTP specifications: „The client did not produce a request within the time that the server was prepared to wait. The client MAY repeat the request without modifications at any later time.
409ConflictIndicates that the request could not be processed because of conflict in the current state of the resource, such as an edit conflict between multiple simultaneous updates.
410GoneIndicates that the resource requested is no longer available and will not be available again. This should be used when a resource has been intentionally removed and the resource should be purged. Upon receiving a 410 status code, the client should not request the resource in the future. Clients such as search engines should remove the resource from their indices. Most use cases do not require clients and search engines to purge the resource, and a „404 Not Found” may be used instead.
411Length RequiredThe request did not specify the length of its content, which is required by the requested resource
412Precondition FailedThe 412 error response indicates that the client specified one or more preconditions in its request headers, effectively telling the REST API to carry out its request only if certain conditions were met. A 412 response indicates that those conditions were not met, so instead of carrying out the request, the API sends this status code.
413Payload Too LargeThe request is larger than the server is willing or able to process. Previously called „Request Entity Too Large”
414URI Too LongThe URI provided was too long for the server to process. Often the result of too much data being encoded as a query-string of a GET request, in which case it should be converted to a POST request. Called „Request-URI Too Long” previously
415Unsupported Media TypeThe 415 error response indicates that the API is not able to process the client’s supplied media type, as indicated by the Content-Type request header. For example, a client request including data formatted as application/xml will receive a 415 response if the API is only willing to process data formatted as application/json.
For example, the client uploads an image as image/svg+xml, but the server requires that images use a different format.
416Range Not SatisfiableThe client has asked for a portion of the file (byte serving), but the server cannot supply that portion. For example, if the client asked for a part of the file that lies beyond the end of the file. Called „Requested Range Not Satisfiable” previously.
417Expectation FailedThe server cannot meet the requirements of the Expect request-header field.
421Misdirected RequestThe server cannot meet the requirements of the Expect request-header field.
422Unprocessable EntityThe request was well-formed but was unable to be followed due to semantic errors.
423LockedThe resource that is being accessed is locked.
424Failed DependencyThe request failed because it depended on another request and that request failed (e.g., a PROPPATCH).
425Too EarlyIndicates that the server is unwilling to risk processing a request that might be replayed.
426Upgrade RequiredThe client should switch to a different protocol such as TLS/1.0, given in the Upgrade header field.
428Precondition RequiredThe origin server requires the request to be conditional. Intended to prevent the 'lost update’ problem, where a client GETs a resource’s state, modifies it, and PUTs it back to the server, when meanwhile a third party has modified the state on the server, leading to a conflict.
429Too Many RequestsThe user has sent too many requests in a given amount of time. Intended for use with rate-limiting schemes.
431Request Header Fields Too LargeThe server is unwilling to process the request because either an individual header field, or all the header fields collectively, are too large.
451Unavailable For Legal Reasons A server operator has received a legal demand to deny access to a resource or to a set of resources that includes the requested resource.
500Internal Server Error500 is the generic REST API error response. Most web frameworks automatically respond with this response status code whenever they execute some request handler code that raises an exception.
A 500 error is never the client’s fault, and therefore, it is reasonable for the client to retry the same request that triggered this response and hope to get a different response.
API response is the generic error message, given when an unexpected condition was encountered and no more specific message is suitable.
501Not ImplementedThe server either does not recognize the request method, or it lacks the ability to fulfill the request. Usually, this implies future availability (e.g., a new feature of a web-service API).
502Bad GatewayThe server was acting as a gateway or proxy and received an invalid response from the upstream server.
503Service UnavailableThe server cannot handle the request (because it is overloaded or down for maintenance). Generally, this is a temporary state.
504Gateway TimeoutThe server was acting as a gateway or proxy and did not receive a timely response from the upstream server.
505HTTP Version Not SupportedThe server does not support the HTTP protocol version used in the request.
506506 Variant Also NegotiatesTransparent content negotiation for the request results in a circular reference.
507Insufficient StorageThe server is unable to store the representation needed to complete the request.
508Loop Detected
The server detected an infinite loop while processing the request (sent instead of 208 Already Reported).
510Not ExtendedFurther extensions to the request are required for the server to fulfil it.
511Network Authentication RequiredThe client needs to authenticate to gain network access. Intended for use by intercepting proxies used to control access to the network (e.g., „captive portals” used to require agreement to Terms of Service before granting full Internet access via a Wi-Fi hotspot).

Decline Codes

An unsuccessful response comprises both different HTTP status (400,401. 403, 405, 429, 500 and 503) a returnStatus.statusCode other than „000” and a returnStatus.StatusDescription associated with different error descriptions.

Interfejsy API SIBS Stargate wykorzystują predefiniowane kody statusu, które odnoszą się do potencjalnych przyczyn nieudanej odpowiedzi. Poniższa tabela przedstawia różne kody odrzuceń (statusCode), opisu(StatusDescription) i przyczynę potencjalnego odrzucenia.

Poniższa tabela zawiera różne kody statusu, odpowiadające im opisy i sugerowane działania w celu rozwiązania błędów

statusCodeStatusDescriptionDecline ReasonSuggested action
E0101Nieprawidłowe żądanie, brakuje danych lub są one nieprawidłoweDane wprowadzone dla transakcji nie są poprawne, więc transakcja nie mogła zostać zainicjowana lub pomyślnie zakończona.Sprawdź, czy dane wprowadzone dla transakcji są prawidłowe i dokładne.
Upewnij się, że dane takie jak informacje o karcie, informacje o kliencie i dane mandatu SEPA DD są prawidłowe.
E0102Nieprawidłowe lub brakujące dane dla typu płatnościNie można było zweryfikować typu płatności i danychSprawdź poprawność danych płatności (dotyczy Blik i kart).
E0103Uwierzytelnianie 3D Secure nie powiodło sięProces uwierzytelniania 3DS nie został pomyślnie zakończony przez kupującegoTerminal powinien mieć aktywne 3DS i
karta używana podczas transakcji powinna również obsługiwać 3DS.
E0104Przekroczony limit kwotyKwota transakcji (w tym upoważnienie SEPA DD) nie spełnia limitów sieci akceptacjiDla SEPA DD:
Verify the transaction limits imposed by the bank.
Upewnij się, że polecenie zapłaty SEPA jest poprawnie skonfigurowane.

Dla BLIK:
Kupujący powinien sprawdzić limity i saldo konta BLIK.

Dla kart:
Sprawdź limity transakcji dla danej transakcji.
E0105Autoryzowana płatność – Nieprawidłowa metoda płatnościSprzedawca albo nie ma dostępnej metody płatności, albo nie skonfigurował jej poprawnie do przetwarzania transakcji.Sprawdź w SIBS Backoffice, czy istnieje dostępna umowa dla wybranej metody płatności, aby upewnić się, że transakcja się powiedzie.
E0106Niepoprawny terminal.Żądana transakcja nie jest obsługiwana przez terminalSprawdź, za pośrednictwem SIBS Backoffice, ustawienia terminala, który został użyty do przeprowadzenia transakcji.
E0107Autoryzowana płatność NieznanyAutoryzacja płatności nie powiodła się lub jej status jest nieokreślony.Sprawdź status transakcji w SIBS Backoffice.
E0108Nieprawidłowa konfiguracja webhookUstawienia webhook zostały skonfigurowane nieprawidłowoSprawdź w menu SIBS Backoffice Webhook, czy ustawienia webhook są prawidłowo zdefiniowane.
E0201Odrzucono, płatność cykliczna jest nieaktywnaPłatność cykliczna może zostać odrzucona, dezaktywowana lub nie być obsługiwana przez sprzedawcę.Please review the checkout details to verify the payment information.
Upewnij się, że wszystkie niezbędne pola płatności są dokładnie wypełnione, w tym numer karty, data ważności, CVV, adres rozliczeniowy i wszelkie inne wymagane informacje.
E0202Operacja odrzuconaPłatność nie została zaakceptowana/odrzucona lub system zarządzania oszustwami nie zatwierdził transakcji.Skontaktuj się z SIBS, aby dowiedzieć się, dlaczego transakcja została odrzucona przez system wykrywania oszustw (dotyczy kart i BLIK).
E0301Błąd poświadczeń sprzedawcyNiepowodzenie w uzyskaniu poświadczeń aplikacji dla sprzedawcyUpewnij się, że podane dane uwierzytelniające dla wywołań API są prawidłowe, a jeśli problem nadal występuje, skontaktuj się z pomocą techniczną SIBS.
E0302Nie znaleziono porozumieniaNieważna umowa dotycząca określonego produktu finansowegoSprawdź w menu SIBS Backoffice, czy umowy finansowe są prawidłowo zdefiniowane.
E0303Operacja nie jest obsługiwanaNie udało się wygenerować transakcji w określonej usłudze (na przykład: Link to Pay, Split Payout).Podaj identyfikator transakcji zespołowi wsparcia SIBS, aby zrozumieć, dlaczego transakcja kończy się niepowodzeniem.
E0304Transakcja została już sfinalizowanaBieżący przepływ transakcji został już zakończony, podobna transakcja mogła już zostać niedawno przesłana.Potwierdzenie w SIBS Backoffice statusu transakcji z danym identyfikatorem transakcji.
E0305Nie znaleziono transakcjiJeśli nie uda się uzyskać informacji o transakcji, należy sprawdzić identyfikator transakcji.Potwierdź status transakcji w SIBS Backoffice.
E0306Nieprawidłowa parametryzacja metody płatnościNieprawidłowa parametryzacja metody płatności (kwota, data wygaśnięcia, token, kod sprzedawcy lub kod terminala)Sprawdź, czy w metodzie płatności nie ma nieprawidłowych parametrów, zapewniając dokładność w polach takich jak kwota, data wygaśnięcia, token, kod sprzedawcy lub kod terminala.
E0307Nieprawidłowa parametryzacja typu płatnościNieprawidłowa parametryzacja w typie płatności (dotyczy autoryzacji, zakupu, przechwycenia lub zwrotu).Zaktualizuj parametryzację typu płatności, aby upewnić się, że dokładnie odpowiada zamierzonej funkcji, niezależnie od tego, czy jest to autoryzacja, zakup, przechwytywanie czy zwrot.
E0900Nieprawidłowe dane uwierzytelniania lub autoryzacjiUtworzenie tokena nie powiodło się z powodu nieprawidłowych danychPotwierdź dane informacyjne tokena.
E0901Nieprawidłowe dane akceptanta, wierzyciela, rachunku lub upoważnieniaMandat SEPA DD nie został poprawnie skonfigurowanyPotwierdź ustawienia upoważnienia SEPA DD.
E0902Nieprawidłowa kwotaKwota płatności jest nieprawidłowa lub przekracza dozwoloną kwotę.Sprawdź szczegóły tokena SEPA DD.
E0903Nieprawidłowa walutaThe terminal does not support or accepts the transaction currencySprawdź szczegóły tokena SEPA DD.
E0904Nieprawidłowy link do płatnościNieprawidłowe ustawienia Link to Pay (wygasłe, zduplikowane lub nieaktywne)Sprawdź w SIBS Backoffice, w menu Link to Pay, czy ustawienia łącza są prawidłowo zdefiniowane.
E0905Nieprawidłowa data upoważnieniaTermin płatności upoważnienia do polecenia zapłaty SEPA przekracza 15 dni, przekraczając limit czasowy.Potwierdź ustawienia upoważnienia SEPA DD (data).
E0906Nieprawidłowy kod sprzedawcy lub terminalaDane dotyczące kwoty, daty wygaśnięcia, tokena, kodu sprzedawcy lub kodu terminala nie są prawidłowo zdefiniowane.Sprawdź w SIBS Backoffice, czy dane sprzedawcy, sklepu i terminala są prawidłowo zdefiniowane.
E0908Nieprawidłowe punkty rozliczeniowePunkty rozliczeniowe są nieprawidłowo zdefiniowane lub nie można ich zlokalizować.Sprawdź zarówno w SIBS Backoffice, jak i Checkout API, czy ustawienia punktów rozliczeniowych są prawidłowo zdefiniowane.
T999Tymczasowy błąd SIBSWystąpił wewnętrzny błąd SIBS Gateway. Skontaktuj się z pomocą techniczną, aby uzyskać pomoc.Skontaktuj się z pomocą techniczną SIBS.
E999Błąd wewnętrzny SIBSWystąpił wewnętrzny błąd SIBS Gateway. Skontaktuj się z pomocą techniczną, aby uzyskać pomoc.Skontaktuj się z pomocą techniczną SIBS.

Code references

Kody służą jako kluczowe identyfikatory w różnych domenach, w tym w sferze płatności.

Poniżej znajdują się kody ISO używane dla:

Country

ISO 3166-1 Alpha-2

W przypadku interfejsu API (FULL CODE) onboardingu należy użyć kodu numerycznego ISO3166.

Language