The SDK Initialization
After you install the SDK in your own project, you can start to use the component functionality (i.e. the public APIs) of the SDK, but first, you need to initialize the SDK as shown in this chapter. Before looking at the code though, you should understand how the Public Test environment works.
Using the Public Test Environment
All Wirecard partners who develop with the SDK are provided with:
- a Wirecard card reader hardware device that can be used for testing purposes
- a user name and password that can be used to access the Public Test back-end testing environment
Note
Your user's credentials are usually shipped with expired password so you have to change password after first login.
As part of your initialization code (a sample of which is shown below), you must point the SDK to a back-end environment. An environment essentially means a Switch back-end, as described in the mPOS Architecture. Eventually, you will point to the live/production environment of the merchant for whom you are developing the payment acceptance app. However, during development, you can take advantage of our Public Test environment. This is a fully-functional back-end that you can use throughout development and testing. All endpoints are accessible also in Swagger.
Note
Talk to your project manager if you do not yet have a user name and password for accessing Public Test. If your project manager does not yet have this information, email pos-solutions@wirecard.com with a request to obtain a user name and password and include the relevant data from your partnership agreement. They will be happy to help you.
Tip
We often use the term credentials to refer to both the user name and the password.
Tip
On iOS, After initializing the ePOS SDK, you can set setDevMode to true. This will prompt logs in your console as well as saving your payment flow info into text files in your app's document folder. You can export this text files in case you need technical support later - but it is NOT recommended to leave devMode as true in production/app store versions. Additionally, you can set the log level with ddSetLogLevel, so you can adjust how much info you want in your console.
Also, we suggest you setReducingDataConsumption to true. This will exclude parameters that may not be necessary from nested objects in response.
The Wirecard ePOS class
The highest-level class in the object hierarchy is:
- WDePOS class for iOS platform
- EposSdk class for Android platform
The first step in using Wirecard ePOS SDK is to instantiate this object as shown in the sample code below.
The Sample Code
The sample code demonstrates how to initialize the SDK.
Note that the WDEnvironmentPublicTest
is passed to setupWithEnvironment
method. This points your payment app to the Public Test environment. Substitute your actual user name and password where instead of yourUsername
and yourPassword
. Also note that if there is a current user and a current cashier, both are returned. The cashier is important if you are using the Cash Management functionality of the SDK because every cash operation requires an associated cashier.
As part of the instantiation, notice in the code below that the Env
is set to SWITCH_TEST
. This points your payment app to the Public Test Switch back-end. To work properly, valid credentials must be passed so substitute in your actual user name instead of username
and use your actual password instead of password
in the setCredentials
method. Also note that the extensions that you should include will depend on the hardware that you will use with the payment app. The Spire Spm2
terminal is Wirecard's standard card reader device. Datecs
is a commonly used printer.