The Sandbox environment is a dedicated environment for integration purposes. It is located at https://sandbox.payware.eu/. Its API endpoint is located at https://sandbox.payware.eu/api/.
When a partner registers through the Portal he is automatically given Sandbox API credentials. All of them are accessible in the Settings section of the portal.
As described in the Authentication sections, in order to make requests against the payware engine you need two things:
- your Partner ID
- an asymmetric RSA key pair, exchanged with payware
¶ Sandbox Partner ID
The Sandbox API recognizes the same Partner ID which is provided to you during registration and is used for production operations.
You can find it in the Settings section of the portal.
¶ RSA Key Pair
payware generates an RSA key pair for usage with the Sandbox API.
You are not expected to generate one yourself and provide the public key - instead, you should take the private key from the Portal and sign your requests against the Sandbox API with it.
Note: it is highly discouraged to use the same private key to sign requests against the Production API. See security considerations below.
¶ Sensitive Information And Sandbox Security
The Sandbox environment should be considered inherently unsafe. It does not have the same strong security guarantees the production API has. Its data might be deleted and should not be relied on.
payware does not keep any sensitive information regarding its partners on the Sandbox API and partners are encouraged to obfuscate any data they send towards it.
Sandbox transactions’ data is reset at every month beginning.
¶ Merchant Sandbox Settings
Merchants only have the RSA Key Pair generated by payware in their sandbox settings.
This is everything needed to start the integration process.
Description of fields on Settings->Sandbox->Your Data:
| Field | Description | Usage |
|---|---|---|
| Private Key | The private key of the merchant | Sign JWT tokens for operational API communication |
| payware Public Key | The payware public key | Verify JWT signature of incoming callback requests |
In production you are limited to the merchant endpoint only.
¶ ISV Sandbox Settings
ISVs have the same private and public key on Settings->Sandbox->Your Data.
In addition to that, the sandbox settings contain the information of two test merchants.
ISVs can use either of those merchants as authorizers for making requests against the Sandbox API, as well as implementing the authorization OAuth2 flow.
Description of fields on Settings->Sandbox->Merchant's Data:
| Field | Description | Usage |
|---|---|---|
| Partner ID | The partner ID of the given merchant | 1. clientId for OAuth2 requests2. aud JWT claim for operational API communication |
| Partner Secret | The secret of the given merchant | clientSecret for OAuth2 requests |
| Authorization Token | A generated authorization access token (as would have been generated by the OAuth2 API) | sub JWT claim for operational API communication |
| Authorization Granted (toggle) | Toggle the state of the token between GRANTED and REVOKED |
Test authorization token flows UX (see diagrams on Authorization page) |
| Shop Code | The shop you operate on that test merchant | shop on transaction requests, shopCode when creating a POI |
Use your own Shop Code, not the merchant’s. The two test merchants are shared by every ISV, but a
shop is not: a merchant assigns each of its shops to one ISV, and you may only work in yours. The
shop code in your sandbox settings is the one created for you on that merchant - use it wherever a
request takes a shop. Another ISV’s shop, or the merchant’s own, answers 403
ERR_SHOP_NOT_IN_SCOPE.This mirrors production exactly, which is the point: an integration certified against a sandbox that
ignored shop assignment would meet its first 403 on go-live day. In production a merchant that
reaches payware through your invitation has its first shop assigned to you automatically; a merchant
that already existed assigns one in its portal, under Business places -> Operated by.
In production, access tokens have a 180-day expiration period and can be rotated by the ISV via
POST /oauth2/tokens/{token}/rotate. Sandbox tokens do not expire.
In production you are limited to the merchant endpoint only.
¶ Financial Institution Sandbox Settings
Financial Institutions have the RSA Key Pair generated by payware in their sandbox settings.
This is everything needed to start the integration process.
Description of fields on Settings->Sandbox->Your Data:
| Field | Description | Usage |
|---|---|---|
| Private Key | The private key of the financial institution | Sign JWT tokens for operational API communication |
| payware Public Key | The payware public key | Verify JWT signature of incoming callback requests |
In production you are limited to the financial institution endpoint only.
¶ Test toolkit
payware provides a set of integration tools. Their use is not required for a successful integration. The same functionality is available through payware APIs and partners are free to use them as testing mean.
¶ Mobile banking / E-wallet Application
Merchants can verify the generated qr/barcodes with the payware FI toolkit. Install the application from 
.
The Android application scans qr/barcodes generated in the Sandbox environment. It allows creation of parametrized transactions. Sharing those via clickable deep links, enables p2p payments across financial institutions.
It has the options to Confirm, Decline or Fail a test transaction (with a reason).
¶ Sandbox webPOS app
Financial institutions can verify mobile banking and e-wallet applications integrations by scanning and processing orders on webPOS app. Using webPOS, payment apps integrators can test payments initiation and processing over:
- NFC (unidirectional: webPOS as reader on Android Chrome)
- Link (unidirectional: webPOS as link provider)
- QR and barcode (bidirectional)
- Text (bidirectional)
Use 111111 or 222222 as webPOS IDs for testing purposes.
¶ POS Shop emulator page
Financial institutions can verify mobile banking and e-wallet applications integrations by scanning and processing orders on POS Demo Store page. The orders have fixed payee, amount, currency and TTL. However, those could be customized through additional parameters in the address bar. See the instructions on the page.
They transaction identifiers are available in QR code, barcode and deep link formats.
¶ Scanner Application
Financial institutions can download an Android app which simulates a scan of the financial institution customer account by the payware Demo Store cashier qr/barcode reader. Within that app you can specify the financial institution id and the account id to be pushed back to your servers. Install the application from