NAV Navbar
1.3.1
shell
  • Welcome
  • Fundamentals
  • Integration
  • Integration Examples
  • Reporting
  • Authorization API
  • Payment API
  • Settlements API
  • Transactions API
  • Direct Withdrawal API
  • KYC info
  • FAQ
  • Release Notes
  • Gfx dots

    Welcome

    alt text

    Welcome to the Zimpler developer hub. Here you will find comprehensive guides and documentation to help you start working with our services as quickly as possible, as well as support if you get stuck.

    We provide

    Our services lets you transfer money back and forth. All methods include full KYC information of the user so it can be tailored to do many things, but essentially we see three main flows:

    1. Deposit
    2. One click sign up/resume
    3. Withdrawal

    All three flows share a common “ID” which conveniently also is the Zimpler wallet account number where money is deposited and withdrawn from. So less to keep track of.

    More info about our services and what we call our closed loop

    Demo

    alt text

    Get a feel for our services by trying out our demo merchant

    Demo code on Github

    To get a better idea of how we intend everything to tie together you can check out the demo code that is available on Github.

    How to read this document

    This document is split up into three main part where the first gives a brief overview of how things works and how you can integrate with us and our services. Next part is intended to give you a more in depth step by step on how the flow of login, depositing and withdrawing of funds are done. The last part is the api specification detailing each service endpoint.

    Fundamentals

    alt text

    All requests should be made over HTTPS. All request and response bodies, including errors, are encoded in JSON. All requests are expected to be UTF-8 encoded.

    Zimpler payment solution provides the following guarantees to the Merchant:

    1. Each User is identified and has a unique Zimpler user ID
    2. The Merchant will receive the KYC data used by Zimpler to approve each transaction
    3. Each withdrawal can be tied to a User through Zimpler user ID

    So each resource has an identifier assigned to it by Zimpler. It is always called id and it acts as the primary ID for that resource. Whenever an API action is required by the Merchant, the Merchant uses id to construct the relevant URL.

    Some resources allow the Merchant to set their own identifier called ref. The ref attribute is set by the Merchant and Zimpler returns it as it was received during the resource creation process. Generally, there is no correlation between ref and id.

    Some resources may be associated with a User. For these resources it is possible to set account_ref at the time of their creation. The account_ref attribute then represents the Merchant's identifier for the User that is associated with the resource.

    Requirements

    HTTPS

    All requests to the API must use be encrypted with SSL/TLS. Never use plain HTTP without any encryption.

    Content-Type

    Whenever a POST request to the API includes a body with JSON, you need to add the appropiate Content-Type (i.e. Content-Type: application/json) in the HTTP header.

    HTTP persistent connection

    We discourage the use of HTTP keep-alive because this will result in connection errors since we do round-robin on our load balancers.

    GUI Size

    The script requires 500px in width and 560px in height on the website to be fully visible. Remember to allow scrolling if you decide upon a smaller viewport.

    Environments

    Sandbox

    We provide an sandbox environment for integration and testing at:

    https://api-sandbox.zimpler.net

    Make sure that you use our sandbox for testing before you are certain everything works as intended.

    While playing around in our sandbox you can either use a real phone or use the following supported numbers to bypass code verification:

    Pin code is always 1234

    As Bank account one can use the IBAN SE3550000000054910000003 when making a withdrawal.

    Production

    When we have completed the integration and KYC processes you will be handed you credentials to our production environment that can be found at:

    https://api.zimpler.net

    Authentication

    Example of BasicAuth header

    Authorization: Basic ZXhhbXBsZS1tZXJjaGFudC1yZWY6ZXhhbXBsZS1wYXNzd29yZA==
    

    Authenticate your request by including your secret key in API requests. The API uses basic authentication for all calls and you will be given a merchant-id as username and a string as password by Zimpler.

    Basic authentication is supported directly by most HTTP libraries. Preferable use the built in functionality if available.

    If your library doesn’t support Basic authentication, you can manually add it by supplying the Authorization HTTP header with the string Basic followed by a space and a base64 encoded string containing your merchant-id:password combination. See the example to the right.

    Disable client side caching

    To ensure that a new authorization ID is generated on each payment attempt, add:

    response.headers["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
    response.headers["Pragma"] = "no-cache" # HTTP 1.0.
    response.headers["Expires"] = "0" # Proxies.

    Merchant credentials

    Merchant credentials are your secrets to keep. We have no access to them and if they get compromised, Zimpler will be forced to revoke them and generate new ones instead. This would require an immedate action both from the Merchant's and Zimpler's side. Never share merchant credentials in plain-text. Not even with us.

    Supported countries and currencies

    Currently Zimpler supports deposits in three countries:

    In each of these countries any of the following currencies may be used:
    SEK, EUR or USD.

    Withdrawal is available in:

    For Sweden we allow transactions in SEK and for Finland in EUR.

    Minimum deposit amount

    The minimum amount for deposits is 3 SEK, €0.3 or $0.3.

    Maximum deposit amount

    Note that limits for max allowed amount are dynamic and individual.
    Refer all end users with questions about limits to our support by email
    or by phone at +46 (0)775-161 740.

    Maximum withdrawal amount

    Default is €2000 or equivalent in other currencies but can be tailored to fit other needs.

    All attributes listed here are tagged according to their relevance. REQUIREDis what you have to submit, RECOMMENDEDare those that will add to the user experience and relieve the user from having to type in their phone number and tailor their experience better.

    In addition, some attributes, like phone numbers, might need to be properly spelled to be accepted.

    Response codes

    Our API returns standard HTTP success or error status codes. For errors we also return a json body detailing why it went wrong.

    The HTTP status codes we return are listed here:

    Code Title Meaning
    200 OK On successful requests. Returns the requested resource(s)
    201 Created On successful resource creation. Returns the created resource
    400 Bad Request On bad syntax in the request body
    401 Unauthorized On wrong or missing credentials
    403 Forbidden The request requires user authentication
    404 Not Found Resource not found
    409 Conflict On syntactically correct requests that still cannot be performed
    410 Gone This is not the endpoint you are looking for.
    429 Too Many Requests Wait
    5xx Zimpler server error We messed up

    Integration

    Our integration process

    1. Try our demo using a test number
    2. Contact our sales team and request access to our sandbox.
    3. Integrate with us by following the guides for deposit and withdrawal.
    4. Test your Zimpler integration and verify that it passes our acceptance test.
    5. Provide access to your staging area and we will verify that your implementation with us works.
    6. After the acceptance test is passed, we will send you the details regarding your live merchant account.
    7. Switch all end points to api.zimpler.net and change to the live merchant account.
    8. Go live with the integration for all users.

    Acceptance test

    1. Flows

    2. Call parameters

    Service Presentation

    These are the marketing requirements and best practices to get the best results with Zimpler.

    Please bear in mind that the Zimpler brand is not to be marketed in a way that interferes with national and/or European legislation.

    Marketing must be performed in accordance with good practice. Good practice means to promote Zimpler with texts and logos in accordance with this document and follow rules and recommendations for responsible gaming. We are happy to assist you with creating marketing campaigns.

    1. Describe Zimpler correctly in Cashier

    The bare minimum is to display our logo in the cashier. It is designed for optimal conversion. (Right click and Save as).

    Zimpler cashier logo

    If required, the following texts must be used to describe the Zimpler service.

    Please do not make any alterations to the texts.

    English:
    "Bank transfer, card or invoice"

    Swedish:
    “Banköverföring, kort eller faktura”

    Finnish:
    "Pankkisiirto, kortti tai lasku"

    German:
    "Bezahl mit Bankkonto oder Kreditkarte"

    2. For Payment Description pages use the following localised texts

    The following texts must be used.

    Please do not make any alterations to the texts.

    English:
    "Pay from bank account, card or bill in a fast and secure way."

    Swedish:
    "Betala via bank, kort eller faktura på ett snabbt och säkert sätt."

    Finnish:
    "Pankkin kautta, korttilla tai laskulla maksetaan nopeasti ja turvallisesti."

    German:
    "Bezahl mit Bankkonto oder Kreditkarte. Schnell, sicher und bequem"

    3. Notify your users that you have added Zimpler

    Inform your end users that you have added support for Zimpler on your site and through a newsletter.

    Integration Examples

    Here is the main three integrations explained step by step

    Deposit flow

    The deposit flow is based on two components, server to server communication via HTTPS and an embedded javascript. The javascript is embedded directly in the Merchants cashier which creates a nice user experience without any redirects or similar.

    Deposit flow-chart

    alt text

    1. User wants to make a payment using Zimpler.
    2. Merchant then initiates the session by creating an authorization with a nested payment that includes the requested amount.
    3. Merchant embeds the Zimpler script in the page returned to the User. The User then identifies himself and authorizes the payment through the form rendered by the script.
    4. On success, the JavaScript callback will be called, and control is handed back to the server.
    5. Merchant then checks the authorized amount by retreiving the authorization.
    6. Merchant asks for KYC information concerning the customer.
    7. Merchant captures the authorized amount.
    8. Merchant returns a page to the User informing him of the successful payment.

    Initiating a deposit

    The intial authorization request

    $ curl 'https://api-sandbox.zimpler.net/v3/authorizations'
      -u 'test-account:test-account-key'
      -H 'Content-Type: application/json'
      -d '
        {
          "method": "web",
          "type": "payment",
          "payment": {
            "ref": "payment_48832",
            "type": "flexible_amount",
            "requested_amount": "200.00",
            "requested_min_amount": "200.00",
            "currency": "SEK"
          },
          "locale": "sv",
          "country": "SE",
          "national_identification_number": "19840307-4910",
          "mobile_phone": "+46700000000",
          "email": "bobben@example.com",
          "site": "exampledomain.com",
          "account_ref": "PlayerRef1234"
        }
    

    The first step to a successful payment is to create the authentication resource. This will be used by the Zimpler JavaScript. Some notes on the attributes:

    A typical response when initiating a deposit

    {
      "id":"824e6fb208bd944f652f",
      "method":"web",
      "state":"pending",
      "type":"payment",
      "payment":
        {
          "id":"16a05b2ac80ec8330cae",
          "ref":"payment_48832",
          "state":"pending",
          "type":"flexible_amount",
          "requested_amount":"200.00",
          "requested_min_amount":"200.00",
          "authorized_amount":null,
          "captured_amount":null,
          "currency":"SEK",
          "created_at":"2018-09-10T07:05:07Z",
          "expires_at":null,
          "items":null
        },
      "country":"SE",
      "mobile_phone":"+46700000000",
      "national_identification_number": "19840307-4910",
      "verified_mobile_phone":null,
      "email": "bobben@example.com",
      "site": "exampledomain.com",
      "account_ref":"PlayerRef1234",
      "created_at":"2018-09-10T07:05:07Z"
    }
    

    In the response, you will get the newly created authorization, including all the information you submitted along with other attributes that belong to the authorization and the nested payment resources.

    The state of both the authorization and the payment are set to pending until the user has authorized the payment.

    Fast KYC

    The fastKYC callback response where the merchant is declining the transaction

    {"accepted_amount": "0.00"}
    

    The fastKYC callback body

    {
      "kyc": {
        "user_id":"e89918b4-3162-eb6d-c747-77d19b19ece6",
        "national_identification_number":"19840307-4910",
        "full_name":"John Doe",
        "first_name":"John",
        "last_name":"Doe",
        "date_of_birth":"1984-03-07",
        "country_code":"SE",
        "pep":false,
        "address_line_1":"123 sesame street",
        "address_line_2":null,
        "address_postcode":"123456",
        "address_city":"Sudden Valley",
        "address_country":"Sweden"
      },
      "authorization": {
        "id":"824e6fb208bd944f652f",
        "method":"web",
        "state":"pending",
        "type":"payment",
        "payment":
          {
            "id":"16a05b2ac80ec8330cae",
            "ref":"payment_48832",
            "state":"pending",
            "type":"flexible_amount",
            "requested_amount":"200.00",
            "requested_min_amount":"200.00",
            "authorized_amount":null,
            "captured_amount":null,
            "currency":"SEK",
            "created_at":"2018-09-10T07:05:07Z",
            "expires_at":null,
            "items":null
          },
          "country":"SE",
          "mobile_phone":"+46700000000",
          "verified_mobile_phone":null,
          "email": "bobben@example.com",
          "site": "exampledomain.com",
          "account_ref":"PlayerRef1234",
          "created_at":"2018-09-10T07:05:07Z"
        }
      }
    

    NOTE THAT THIS IS NOT PART OF THE STANDARD FLOW, BUT A CONVENIENCE FEATURE FOR A SPECIFIC TYPE OF DEPOSITS

    If it is necessary to get the User's details as soon as possible, perhaps to deny banned users or to align deposit amount to a spending limit, there exist a way to get this information before authorization is accepted by the User.

    To enable this, add the extra attribute kyc_callback_url into the payment object. Merchant should then be ready to accept a POST call to this url with user detail payload as soon as the User has been identified.

    Upon receiving the kyc information, the Merchant needs to respond to continue the transaction. This is done by replying with the field accepted_amount that holds the amount as a string (see response example in code column). Here the Merchant has the option to either change the amount to a lower value or decline the transaction entirely by setting the accepted_amount to "0.00". Note that the user will be prohibited from proceeding until you have replied. If declined, the user will be notified through our javascript.

    Embed the javascript form in your checkout

    Embed the following code in your checkout

    <head>
      <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />
    </head>
    
    <!-- 1. Element where the form is inserted. -->
    <div id="zimpler-authorize"></div>
    <!-- 2. Zimpler JavaScript. -->
    <script src="https://api-sandbox.zimpler.net/assets/v3/zimpler.js"></script>
    <!-- 3. Define callback and call authorize. -->
    <script type="text/javascript">
      var onSuccess = function() {
        document.getElementById("success-form").submit();
      };
      Zimpler.authorize("824e6fb208bd944f652f", onSuccess);
    </script>
    
    <!-- 4. Form used for posting on authorization success. -->
    <form id="success-form" action="authorized" method="POST"></form>
    

    Once you have created the authorization, you will need embed the Zimpler JavaScript on the returned HTML page. The JavaScript will generate a multistep form that is used for the User to identify himself, and to authorize the payment. This process is completely transparent to the Merchant. However, once the payment is authorized, you will be notified through the JavaScript callback.

    The code consists of several parts:

    1. The block element where the Zimpler form will be inserted.
    2. The script tag that loads the Zimpler JavaScript.
    3. The JavaScript where you define the callback and call authorize. The first parameter to authorize is the authorization ID. The second is the JavaScript function that gets called on authorization success. There is no callback for an authorization failure.
    4. On success, you can do anything you want, but a common pattern is to submit a form available on the page.

    Retrieve KYC information

    Get the user information

    $ curl 'https://api-sandbox.zimpler.net/v3/authorizations/824e6fb208bd944f652f/kyc'
    -u 'test-account:test-account-key'
    

    At this point, when the verification by the customer is complete, the Merchant can opt to get the full KYC information, that we have gathered, of the customer. This contains the unique identifier user_id that can be used to make sure that by withdrawal, the money indeed goes back to same person.

    A typical kyc response

    {
      "user_id":"e89918b4-3162-eb6d-c747-77d19b19ece6",
      "national_identification_number":"19840307-4910",
      "full_name":"John Doe",
      "first_name":"John",
      "last_name":"Doe",
      "country_code":"SE",
      "date_of_birth":"1984-03-07",
      "pep":false,
      "address_line_1":"123 sesame street",
      "address_line_2":null,
      "address_postcode":"123456",
      "address_city":"Sudden Valley",
      "address_country":"Sweden"
    }
    

    Check the status

    Get the approved amount from the authorization object

    $ curl 'https://api-sandbox.zimpler.net/v3/authorizations/824e6fb208bd944f652f' \
      -u 'test-account:test-account-key'
    

    The response.

    {
      "id":"824e6fb208bd944f652f",
      "method":"web",
      "state":"approved",
      "country":"SE",
      "mobile_phone":"+46700000000",
      "verified_mobile_phone":"+46700000000",
      "email":"bobben@example.com",
      "site": "exampledomain.com",
      "account_ref":"PlayerRef1234",
      "created_at":"2018-09-10T07:05:07Z",
      "type":"payment",
      "payment":
        {
          "id":"16a05b2ac80ec8330cae",
          "ref":"payment_48832",
          "state":"authorized",
          "type":"flexible_amount",
          "requested_amount":"200.00",
          "requested_min_amount":"200.00",
          "authorized_amount":"200.00",
          "captured_amount":null,
          "currency":"SEK",
          "created_at":"2018-09-10T07:05:07Z",
          "expires_at":"2018-09-10T07:08:18Z",
          "items":null
        }
    }
    

    In the response you can see that only 180 SEK were authorized which is the maximum amount that can be captured.

    You can see the authorization's state change from pending to approved and the payment’s state to change from pending to authorized.

    Capture payment

    A capture request

    $ curl 'https://api-sandbox.zimpler.net/v3/payments/16a05b2ac80ec8330cae/capture' \
      -u 'test-account:test-account-key' \
      -H 'Content-Type: application/json' \
      -d '
        [
          {
            "title": "Payment at exampledomain.com",
            "vat_percentage": "25.00",
            "unit_price_including_vat": "200.00"
          }
        ]
      '
    

    While an authorized payment has the amount reserved, it still needs to be captured. On capture, you also specify the items on the payment that will be printed on the invoice. Make sure that this means sense to the end customer. If someone was bought on a certain page, it makes sense that this page title is also written on the invoice.

    The capture response

    {
      "id":"16a05b2ac80ec8330cae",
      "authorization_id":"824e6fb208bd944f652f",
      "ref":"payment_48832",
      "state":"captured",
      "type":"flexible_amount",
      "requested_amount":"200.00",
      "requested_min_amount":"200.00",
      "authorized_amount":"200.00",
      "captured_amount":"200.00",
      "currency":"SEK",
      "created_at":"2018-09-10T07:05:07Z",
      "expires_at":null,
      "items":
        [{
          "title":"Payment at exampledomain.com",
          "quantity":null,
          "vat_percentage":"25.00",
          "unit_price_including_vat":"180.00"
        }]
    }
    

    The returned payment has changed state from authorized to captured. The captured amount is set to 400 SEK, and the items are also included in the response. This is the final part of the deposit flow. Once you receive a Capture response then the payment is fully completed.

    Release a payment

    Release request for a payment that has not yet been captured

    $ curl -X "POST" 'https://api-sandbox.zimpler.net/v3/payments/72fb9742e1a6c5aa10bd/release' \
      -u 'test-account:test-account-key'
    

    Sometimes things need to be changed afterwards. Depending on which state the deposit is in when the Merchant wishes to abort it, there is two ways ahead:

    Revoke request for a payment that has been captured

    $ curl -X "POST" 'https://api-sandbox.zimpler.net/v3/payments/72fb9742e1a6c5aa10bd/revoke' \
      -u 'test-account:test-account-key'
    

    Sign up/resume flow

    The following steps describe a typical identification flow. The identification flow is based on two components, server to server communication via HTTPS and an embedded javascript. The javascript is embedded directly in the Merchants cashier which creates a nice user experience without any redirects or similar.

    Login flow-chart

    alt text

    1. User wants to identify themselves using Zimpler.
    2. Merchant then initiates the session by creating an authorization with a login type.
    3. Merchant embeds the Zimpler script in the page returned to the User. The User then identifies themselves and confirm.
    4. On success, the JavaScript callback will be called, and control is handed back to the server.
    5. Merchant asks for KYC information concerning the customer.

    Initiating a session

    An example request to initiate a login.

    $ curl 'https://api-sandbox.zimpler.net/v3/authorizations'
      -u 'test-account:test-account-key'
      -H 'Content-Type: application/json'
      -d '
        {
          "method": "web",
          "type": "login",
          "locale": "sv",
          "country": "SE",
          "national_identification_number":"19840307-4910",
          "mobile_phone": "+46712345678",
          "email": "bobben@example.com",
          "site": "exampledomain.com",
          "account_ref": "PlayerRef1234"
        }
    

    The first step to a successful login is to create the authentication resource. This will be used by the Zimpler JavaScript. Some notes on the attributes:

    An example response when initiating a login

    {
      "id": "6bdd0f7bc673c1301d0d",
      "method": "web",
      "type": "login",
      "state": "pending",
      "country": "SE",
      "national_identification_number": "19840307-4910",
      "mobile_phone": "+46712345678",
      "verified_mobile_phone": null,
      "email": "bobben@example.com",
      "site": "example.com",
      "account_ref": "PlayerRef1234",
      "created_at": "2018-11-10T14:21:11Z"
    }
    

    In the response, you will get the newly created authorization, including all the information you submitted along with other attributes that belong to the authorization.

    The state of the authorization is set to pending until the user has authorized the identification.

    Embed the javascript form

    <head>
      <meta name="viewport" content="width=device-width, initial-scale=1, user-scalable=no" />
    </head>
    
    <!-- 1. Element where the form is inserted. -->
    <div id="zimpler-authorize"></div>
    <!-- 2. Zimpler JavaScript. -->
    <script src="https://api-sandbox.zimpler.net/assets/v3/zimpler.js"></script>
    <!-- 3. Define callback and call authorize. -->
    <script type="text/javascript">
      var onSuccess = function() {
        document.getElementById("success-form").submit();
      };
      Zimpler.authorize("6bdd0f7bc673c1301d0d", onSuccess);
    </script>
    
    <!-- 4. Form used for posting on authorization success. -->
    <form id="success-form" action="authorized" method="POST"></form>
    

    Once you have created the authorization, you will need embed the Zimpler JavaScript on the returned HTML page. The JavaScript will generate a multistep form that is used for the User to identify themselves, and to authorize the identification. This process is completely transparent to the Merchant. However, once the identification is authorized, you will be notified through the JavaScript callback.

    The code consists of several parts:

    1. The block element where the Zimpler form will be inserted.
    2. The script tag that loads the Zimpler JavaScript.
    3. The JavaScript where you define the callback and call authorize. The first parameter to authorize is the authorization ID. The second is the JavaScript function that gets called on authorization success. There is no callback for an authorization failure.
    4. On success, you can do anything you want, but a common pattern is to submit a form available on the page.

    Retrieve the KYC

    $ curl 'https://api-sandbox.zimpler.net/v3/authorizations/6bdd0f7bc673c1301d0d/kyc' \
    -u 'test-account:test-account-key' \
    

    At this point, when the verification by the customer is complete, the Merchant should fetch the full KYC information that we have gathered. This contains the unique identifier user_id that can be used to make sure that the same person returns for deposit or withdrawal.

    Example KYC response

    {
      "user_id" : "0f834594-3839-b9b7-8f7b-9c9f16793d4e",
      "national_identification_number" : "19840307-4910",
      "full_name" : "Foo Bar",
      "first_name" : "Foo",
      "last_name" : "Bar",
      "date_of_birth" : "1981-01-01",
      "country_code" : "SE",
      "pep" : false,
      "address_line_1" : "Gulgatan 3",
      "address_line_2" : "lgh 1205",
      "address_postcode" : "49123",
      "address_city" : "Blablaborg",
      "address_country" : "Sweden"
    }
    

    The user is now identified!

    Direct Withdrawal flow

    A request to initiate a withdrawal with user_id known

    $ curl 'https://api-sandbox.zimpler.net/v3/withdrawals/direct'
      -u 'test-account:test-account-key'
      -X POST
      -H 'Content-Type: application/json'
      -d '{
        "approved_amount": "500.00",
        "currency": "SEK",
        "user_id": "351e5a43-bf91-73e6-eca1-9fdff28f0332",
        "site":"blahaj.com",
        "ref": "ABCD1234"
      }'
    

    The alternative case where merchant KYC details are used instead

    $ curl 'https://api-sandbox.zimpler.net/v3/withdrawals/direct'
      -u 'test-account:test-account-key'
      -X POST
      -H 'Content-Type: application/json'
      -d '{
        "approved_amount": "500.00",
        "currency": "SEK",
        "user_country_code": "SE",
        "national_identification_number": "19160214-9989",
        "bank_account": "SE3550000000054910000003",
        "site": "example.com",
        "ref": "withdraw-123"
     }'
    

    a response where merchant has to give the user the url link

    {
        "email": null,
        "site": "blahaj.com",
        "ref": "ABCD1234",
        "state": "approved",
        "bank_account": null,
        "currency": "SEK",
        "requested_amount": "500.00",
        "kyc_info": {
            "full_name": "John Doe",
            "first_name": "John",
            "last_name": "Doe",
            "address_line_1": "123 sesame street",
            "address_line_2": null,
            "address_postcode": "123456",
            "address_city": "Sudden Valley",
            "address_country": "Sweden",
            "national_identification_number": "19840307-4910",
            "pep": false,
            "country_code": "SE",
            "date_of_birth": "1977-05-04",
            "user_id": "351e5a43-bf91-73e6-eca1-9fdff28f0332"        
        },
        "id": "67fd583c-606a-4f22-9e62-f655703248f6",
        "user_form_url": "https://my.zimpler.com/update/239867189",
        "user_id": "351e5a43-bf91-73e6-eca1-9fdff28f0332",
        "account_ref": null,
        "country": "Sweden",
        "verified_mobile_phone": "+46700000019"
    }
    

    The flow outline is as follows:

    1. You call us requesting a direct withdrawal.
    2. We either accept or throw an error.
    3. Make the value in attribute user_form_url available to the User in the case that we would like the User to add information such as a bank account number.

    There is basically two distinct ways of using this. First is in the case where the Merchant already has the unique user_id which then serves as destination. The latter case is when this identifier is not known, then national_identification_number and country can be used instead.

    When user id is known

    When the User´s user_id is known you can do what we call a "closed loop withdrawal" which basically means that we guarantee that the money goes back to the same User.

    To do this, simply call the endpoint with this user_id as identifier and define the amount and currency as required parameters.

    When user id is not known

    Use this type of direct withdrawal if you lack the user_id. What differs from the closed loop type is that we here instead require the user's national identification number and country as parameters together with the amount and currency. It is also possible to add bank_account which removes the need for caring about the user_form_url in the response since we then have everything we need to process the request.

    User needs to add information

    If we need the user to update their information, it could be that we need a bank account number or wishes the user to go through our KYC in order for us to be able to handle the request, we need you to check for the user_form_url field in the response. If this field is filled, you need to make this accessible for the user. This link directs the User to a session where we will ask the user to update their details. Do this through a redirect or make it available with a button.

    API details here.

    Reporting

    Example response when asking for all transactions

    [
        {
            "id": "46f54600f1eed25a0bc2",
            "type": "capture_payment",
            "occurred_at": "2018-05-16T11:10:42Z",
            "amount": "1.00",
            "country": "SE",
            "fee_amount": "-0.06",
            "currency": "EUR",
            "payment_id": "ed638eb1e1654d9133d1",
            "payment_ref": "SLFF000000003D1947DB",
            "settlement_id": null
        },
        {
            "id": "0ec9f27d848385434004",
            "type": "capture_payment",
            "occurred_at": "2018-05-08T06:26:12Z",
            "amount": "2.00",
            "country": "SE",
            "fee_amount": "-0.13",
            "currency": "USD",
            "payment_id": "740017e4ad12169b8687",
            "payment_ref": "SLFF000000003D0FD5D5",
            "settlement_id": null
        },
        {
            "id": "603c0a6010eefe1ca8af",
            "type": "capture_payment",
            "occurred_at": "2018-05-02T10:13:48Z",
            "amount": "100.00",
            "country": "SE",
            "fee_amount": "-6.50",
            "currency": "SEK",
            "payment_id": "40084d1d701b3ad3475a",
            "payment_ref": "SLFF00000008C46BAD1A",
            "settlement_id": null
        }
    ]
    

    Zimpler offers a flexible reporting API which enables you to export data to your own systems for payments, transactions and settlements. This makes it easy and fast for support agents to find transactions and mitigate problems.

    All data that we provide is also accessible directly from a regular browser if you so wish. The data is displayed with JSON formatting and can easily be converted to cvs or other formats. From this view you can see all the details about the transaction, the amount, which reference you have in your own system, the state of the transaction etc.

    Detailed information can be found in sections detailing Payment API, Transactions API and Settlements API below.

    Authorization API

    Authorizations contain information needed to identify the User from the Merchant side. The authorization should also contain the payment information for this transaction as a nested object when doing a deposit.

    Authorization states

    alt text

    Authorization object

    ATTRIBUTE
    id
    REQUIRED
    string
    resource id created by the service
    method
    REQUIRED
    enum
    web is currently the only supported method
    type
    OPTIONAL
    enum
    either login or payment. Defaults to payment
    state
    REQUIRED
    enum
    One of pending, approved or declined
    payment
    OPTIONAL
    nested resource
    REQUIRED if type is payment. See the attributes of payment object
    locale
    OPTIONAL
    string or null
    The locale used at the Merchant payment page. One of sv, fi, en and de
    country
    RECOMMENDED
    enum
    User’s nationality as given by the Merchant, required when identifying with electronic id
    national_identification_number
    RECOMMENDED
    string or null
    National identification number for User as given by the Merchant
    email
    OPTIONAL
    string or null
    User’s email as given by the Merchant
    mobile_phone
    OPTIONAL
    string or null
    User’s mobile number as given by the Merchant. Used as prefilled value when identifying with pin
    account_ref
    OPTIONAL
    string or null
    Merchant’s User account reference
    site
    OPTIONAL
    string or null
    Site for which the authorization was created
    verified_mobile_phone
    string or null
    Assigned when User has verified their mobile number
    created_at timestamp
    Assigned in response
    first_name
    DEPRECATED
    string or null
    First name of the User as given by the Merchant
    last_name
    DEPRECATED
    string or null
    Last name of the User as given by the Merchant
    address_line_1
    DEPRECATED
    string or null
    First line of endUser’s address as given by the Merchant.
    address_line_2
    DEPRECATED
    string or null
    Second line of User’s address as given by the Merchant
    address_postcode
    DEPRECATED
    string or null
    Post code for User mailing address as given by the Merchant
    address_city
    DEPRECATED
    string or null
    City for User’s mailing address as given by the Merchant
    address_country
    DEPRECATED
    string or null
    Two letter country code for User’s mailing address as given by the Merchant in ISO 3166-1-alpha-2 format
    date_of_birth
    DEPRECATED
    string or null
    User’s date of birth as given by the Merchant
    is_kyc_performed
    DEPRECATED
    boolean or null
    Whether a KYC has been performed for the User by the Merchant
    recurring
    DEPRECATED
    boolean
    Will always be false, assigned in response

    Creating a new authorization

    Creating an authorization is the first step towards a captured payment or a login process.

    /v3/authorizations

    ATTRIBUTE
    method
    REQUIRED
    enum
    Selects which method to use for the authorization. web is the only method thats currently supported. Allowed value is web
    type
    OPTIONAL
    enum
    Either login or payment. Defaults to payment
    payment
    OPTIONAL
    nested resource
    REQUIRED if type payment. Specifies the payment that should be authorized as part of this authorization. The nested attributes are explained under the creating payment section.
    locale
    RECOMMENDED
    string
    The locale used at the Merchant payment page. The JavaScript will use this value to match the language of the rendered form to the Merchant payment page. If locale isn’t set, the form will use the browser suggested locale, or the default locale for the country. Supported values are sv, fi, en and de
    country
    RECOMMENDED
    enum
    User’s nationality. Two letter ISO 3166-1 code. Allowed values are SE, FI and DE
    email
    RECOMMENDED
    string
    User’s email if known
    mobile_phone
    RECOMMENDED
    string
    User’s mobile number if known. International format with leading "+" and no other character than numbers.
    Swedish example: "+46712345678"
    account_ref
    RECOMMENDED
    string or null
    Merchant’s User account identifier as given by the Merchant
    site
    RECOMMENDED
    string
    Site on which the authorization is being created. Required in case Merchant processes payments across different sites.
    first_name
    RECOMMENDED
    string
    First name of the User as given by the Merchant
    last_name
    RECOMMENDED
    string
    Last name of the User as given by the Merchant
    address_line_1
    RECOMMENDED
    string
    First line of User’s address as given by the Merchant
    address_line_2
    RECOMMENDED
    string
    Second line of User’s address as given by the Merchant
    address_postcode
    RECOMMENDED
    string
    Post code for User mailing address as given by the Merchant
    address_city
    RECOMMENDED
    string
    City for User’s mailing address as given by the Merchant
    address_country
    RECOMMENDED
    string
    Two letter country code for User’s mailing address as given by the Merchant in ISO 3166-1-alpha-2 format
    date_of_birth
    RECOMMENDED
    string
    User’s date of birth as given by the Merchant
    national_identification_number
    RECOMMENDED
    string
    National identification number for User as given by the Merchant
    is_kyc_performed
    RECOMMENDED
    boolean
    Whether a KYC has been performed for the User by the Merchant

    Retrieving an authorization

    You can retrieve an authorization by its id.

    /v3/authorizations/{authorization_id}

    URL ARGUMENTS
    authorization_id
    REQUIRED
    The id of a previously created authorization

    Retrieving the kyc object

    You can retrieve the kyc object for a user by the authorization id

    /v3/authorizations/{authorization_id}/kyc

    URL ARGUMENTS
    authorization_id
    REQUIRED
    The id of a previously created authorization

    Listing authorizations

    Previous authorizations can be listed, and they are returned as a JSON array ordered with the newest authorization first.

    /v3/authorizations

    URL ARGUMENTS
    count
    OPTIONAL
    integer default: 100, max: 1000. The limit on the number of objects returned
    start_after_id
    OPTIONAL
    resource id If given, the list will start with the first object after the one with the given id. Use it to paginate through the list

    Payment API

    A payment represents a transfer of funds from the User to the Merchant via Zimpler. On creation, the Merchant requests an amount and Zimpler responds with a matching authorized amount that is reserved and secured until the expiry timestamp. On capture, the User will get a confirmation text message and/or email.

    When capturing the payment, the Merchant specifies the items paid for. This specification is also printed on the invoice.

    A reserved, but uncaptured payment can be released, and a capture payment can be revoked.

    Payment states

    alt text

    STATE
    pending payment is created. Until User has authorized the payment.
    authorized payment reserves the authorized amount.
    declined payment cannot be used.
    expired payment has released its reservations and cannot be used.
    released payment has released its reservations and cannot be used.
    captured payment is fulfilled and creates an invoice.
    revoked payment is reversed. Note that if User payed by invoice, this invoice could already have been sent out to the User and thus the Merchant has to take the proper actions.

    Payment object

    ATTRIBUTE
    id
    REQUIRED
    string
    resource id created by the service
    authorization_id string
    resource id created by the service
    Each payment connected to an authorization.
    Assigned in response
    ref
    RECOMMENDED
    string or null
    Merchant’s payment reference
    state enum
    Any of pending, authorized,expired, declined, captured, released and revoked.
    Assigned in response
    type
    REQUIRED
    enum
    Can be either flexible_amount or fixed_amount.
    requested_amount
    REQUIRED
    string
    Amount requested by the merchant. Needs to defined with two decimals like "200.00"
    requested_min_amount
    RECOMMENDED
    string or null
    An optional minimum amount requested by the merchant. Only relevant when flexible_amount is used
    authorized_amount string or null
    Amount authorized by Zimpler. The amount is reserved and can be captured up until expired (see expires_at below). A capture on an authorized amount is guaranteed to succeed unless expired.
    Assigned in response
    captured_amount string or null
    The amount captured by the merchant.
    Assigned in response
    currency
    REQUIRED
    enum
    The currency of the payment amounts. Any of SEK, EUR and USD
    kyc_callback_url
    OPTIONAL
    string
    Path to where callback during fast KYC authorization will be POSTed.
    created_at timestamp
    Assigned in response
    expires_at timestamp or null
    Expiration time of the current authorized_amount. Is `null for all payment states except authorized and expired. Counted from the time of authorization. For details on the timeout, see here.
    Assigned in response
    items array or null
    Specification of the items paid for on captured payments. Printed on the invoice
    Assigned in response

    Nested Item object

    ATTRIBUTE
    title string
    A short item description that will be printed on the invoice
    unit_price_including_vat string
    The price of this item including VAT
    vat_percentage string
    The VAT in percent for this item
    quantity integer
    Quantity of this item given as an integer

    Retrieve a payment

    $ curl 'https://api-sandbox.zimpler.net/v3/payments/8ddc962ae3121ef4517e'
      -u 'test-account:test-account-key'
      -H 'Content-Type: application/json'
    

    And the response

    [
      {
        "id":"8ddc962ae3121ef4517e",
        "authorization_id":"cf06540b8956f48f6c31",
        "ref":"ExampleRef1",
        "state":"pending",
        "type":"flexible_amount",
        "requested_amount":"20.00",
        "requested_min_amount":"10.00",
        "authorized_amount":null,
        "captured_amount":null,
        "currency":"USD",
        "created_at":"2017-03-28T09:14:42Z",
        "expires_at":null,
        "items":null
      }
    ]
    

    You can retrieve a payment by its id. One common use case is to check the authorized amount after the JavaScript has returned.

    /v3/payments/{payment_id}

    URL ARGUMENTS
    payment_id
    REQUIRED
    resource id
    The id of a previously created payment

    Capture a payment

    A capture request

    $ curl 'https://api-sandbox.zimpler.net/v3/payments/16a05b2ac80ec8330cae/capture' \
      -u 'test-account:test-account-key' \
      -H 'Content-Type: application/json' \
      -d '
        [
          {
            "title": "Payment at exampledomain.com",
            "vat_percentage": "25.00",
            "unit_price_including_vat": "180.00"
          }
        ]
      '
    

    The capture response

    {
      "id":"16a05b2ac80ec8330cae",
      "authorization_id":"824e6fb208bd944f652f",
      "ref":"payment_48832",
      "state":"captured",
      "type":"flexible_amount",
      "requested_amount":"200.00",
      "requested_min_amount":"100.00",
      "authorized_amount":"180.00",
      "captured_amount":"180.00",
      "currency":"SEK",
      "created_at":"2018-09-10T07:05:07Z",
      "expires_at":null,
      "items":
        [{
          "title":"Payment at exampledomain.com",
          "quantity":null,
          "vat_percentage":"25.00",
          "unit_price_including_vat":"180.00"
        }]
    }
    

    /v3/payments/{payment_id}/capture

    Capture the payment as the last step to confirm the payment and activate the invoicing process. Once the payment is captured, the User will get a notification on text message and/or email, and an physical invoice will be sent out later on.

    The Merchant also needs to submit a list of items that specify the payment; these will be printed on the invoice.

    The captured amount will be calculated from the unit prices and quantities of the items.

    URL ARGUMENTS
    payment_id
    REQUIRED
    resource id
    The id of a payment in authorized state
    ARRAY ITEM ATTRIBUTE
    title
    REQUIRED
    string
    A short item description that will be printed on the invoice
    Example: "Acme Stores - Flyswatter 8:58 pm"
    unit_price_including_vat
    REQUIRED
    string
    The price of this item including VAT. Must be given as a string with two decimals. Used to calculate the captured amount.
    Number formatted with two decimal places
    Examples: "59.50", "1000.00"
    Printed on the invoice
    vat_percentage
    REQUIRED
    string
    The VAT in percent for this item. Must be given as a string with two decimals.
    "0.00" means this item is exempt of VAT.
    Examples: "25.00", "0.00".
    Printed on the invoice
    quantity
    OPTIONAL
    integer
    Quantity of this item given as an integer. Defaults to one, but will not be printed on the invoice when not explicitly given. Used to calculate the captured amount

    Releasing a payment

    /v3/payments/{payment_id}/release

    An authorized payment that is not yet captured can be released at any time. The authorized amount will be released, and the payment can no longer be captured.

    URL ARGUMENTS
    payment_id
    REQUIRED
    resource id
    The id of a payment in authorized state

    Revoking a payment

    /v3/payments/{payment_id}/revoke

    A captured payment can be revoked at any time. As an invoice already might have been sent out, revoking should be reserved for cases where the payment was created on false pretenses.

    URL ARGUMENTS
    payment_id
    REQUIRED
    resource id
    The id of a payment in captured state

    Listing payments

    /v3/payments

    Get the 10 most recent payments

    $ curl 'https://api-sandbox.zimpler.net/v3/payments?count=10'
      -u 'test-account:test-account-key'
    
    [
        {
            "id": "f2b046351cc82e23548c",
            "authorization_id": "f061c7c2c0912a889009",
            "ref": "100139998A1202727",
            "state": "captured",
            "type": "fixed_amount",
            "requested_amount": "20.20",
            "requested_min_amount": null,
            "authorized_amount": "20.20",
            "captured_amount": "20.20",
            "currency": "EUR",
            "created_at": "2019-06-28T07:18:28Z",
            "expires_at": null,
            "items": [
                {
                    "title": "zimpler.deposit.title",
                    "quantity": null,
                    "vat_percentage": "0.00",
                    "unit_price_including_vat": "20.20"
                }
            ]
        },
        ...
    ]
    

    Payments can be listed as a JSON array ordered with the newest first.

    URL ARGUMENTS
    count
    OPTIONAL
    integer
    default: 100, max: 1000. The limit on the number of objects returned
    start_after_id
    OPTIONAL
    resource id
    If given, the list will start with the first object after the one with the given id. Use it to paginate through the list

    Timeouts

    There is one timeout in the deposit process:

    NAME
    Immediate decision timeout 180 seconds This timeout starts counting down when the onSuccess JS function is called. Within this time the Merchant must perform a decision regarding the deposit: either capture or release the payment

    Settlements API

    Zimpler will periodically settle payments. A Merchant may use the settlement endpoint to get detailed information about the settlements including the payments, fees and bank transfer for each settlement.

    Upon settlement, Zimpler will transfer the amount to the Merchant bank account. Please note that it will usually take a few days before the funds are available on the account.

    Retrieving a settlement

    /v3/settlements/{settlement_id}

    You can retrieve a settlement by its id.

    URL ARGUMENTS
    settlement_id
    REQUIRED
    resource id
    The id of the settlement

    Listing settlements

    /v3/settlements

    Get the 10 most recent settlements

    $ curl 'https://api-sandbox.zimpler.net/v3/settlements?count=10'
      -u 'test-account:test-account-key'
    

    Get settlements between two time stamps

    $ curl 'https://api-sandbox.zimpler.net/v3/settlements?from_timestamp=2015-01-01T00:00:00Z&to_before_timestamp=2015-01-02T00:00:00Z&start_after_id=6afbd0cbea6c05df1a7a'
      -u 'test-account:test-account-key'
    

    An example response

    [
      {
        "id":"335fd7b4a6f8f8f73b75",
        "transfer_ref":"1234",
        "gross_amount":"400.00",
        "fee_amount":"-26.00",
        "fee_vat_amount":"-6.50",
        "net_amount":"367.50",
        "currency":"SEK","country":"SE",
        "transferred_on":"2017-02-14",
        "created_at":"2017-02-14T13:19:28Z"
      }
    ]
    

    Settlements can be listed as a JSON array ordered with the newest first.

    A maximum of 1000 objects are returned in a single request. Use count and start_after_id to paginate and retrieve more items. To retrieve only items from a certain time period use from_timestamp and to_before_timestamp.

    URL ARGUMENTS
    count
    OPTIONAL
    integer
    default: 100, max: 1000. The limit on the number of objects returned
    start_after_id
    OPTIONAL
    resource id
    If given, the list will start with the first object after the one with the given id. Use it to paginate through the list
    from_timestamp
    OPTIONAL
    timestamp
    If given, returns only settlements created at or after the given timestamp
    to_before_timestamp
    OPTIONAL
    timestamp
    If given, returns only settlements created strictly before the given timestamp

    Listing transactions for a settlement

    /v3/settlements/{settlement_id}/transactions

    Transactions can be listed as a JSON array ordered with the newest first.

    URL ARGUMENTS
    settlement_id
    REQUIRED
    resource id
    The id of the settlement that the transactions belongs to
    count
    OPTIONAL
    integer
    default: 100, max: 1000. The limit on the number of objects returned
    start_after_id
    OPTIONAL
    resource id
    If given, the list will start with the first object after the one with the given id. Use it to paginate through the list

    Transactions API

    Transactions are made available after a payment is captured or revoked, and represent the corresponding amount being captured or revoked, along with the corresponding merchant fees.

    All transactions will then be listable under the corresponding settlement resource once Zimpler settles the transaction.

    Listing transactions

    /v3/transactions

    $ curl 'https://api-sandbox.zimpler.net/v3/transactions?count=10'
      -u 'test-account:test-account-key'
      -H 'Content-Type: application/json'
    

    An example response

    [
      {
        "id":"03634fe30a47a60dac73",
        "type":"capture_payment",
        "occurred_at":"2017-03-23T07:06:11Z",
        "amount":"10.00",
        "country":"SE",
        "fee_amount":"-0.65",
        "currency":"EUR",
        "payment_id":"8870c44d503449b93874",
        "payment_ref":"exampleRef1",
        "settlement_id":null
      },
      {
        "id":"9203ad61fdddfcef87de",
        "type":"capture_payment",
        "occurred_at":"2017-03-23T07:04:08Z",
        "amount":"10.00",
        "country":"SE",
        "fee_amount":"-0.65",
        "currency":"EUR",
        "payment_id":"104a8fb52a49625c0eb5",
        "payment_ref":"exampleRef2",
        "settlement_id":null
      }
    ]
    

    Transactions can be listed as a JSON array ordered with the newest first.

    A maximum of 1000 objects are returned in a single request. Use count and start_after_id to paginate and retrive more items. To retrieve only items from a certain time period use from_timestamp and to_before_timestamp.

    URL ARGUMENTS
    count
    OPTIONAL
    integer
    default: 100, max: 1000. The limit on the number of objects returned
    start_after_id
    OPTIONAL
    resource id
    The list will start with the first object after the one with the given id. Use it to paginate through the list
    from_timestamp
    OPTIONAL
    timestamp
    If given, returns only transactions created at or after the given timestamp
    to_before_timestamp
    OPTIONAL
    timestamp
    If given, returns only transactions created strictly before the given timestamp

    Direct Withdrawal API

    Create a new direct withdrawal

    /v3/withdrawals/direct

    To create a new direct withdrawal request.

    ATTRIBUTE
    user_id
    REQUIRED
    string
    The ID of the payee. Either this value or national_identification_number AND country is required
    national_identification_number
    REQUIRED
    string
    The national identifier. Use this together with country
    country
    REQUIRED
    string
    Two letter country code for User’s mailing address as given by the Merchant in ISO 3166-1-alpha-2 format.
    approved_amount
    REQUIRED
    string
    The amount that the payee will withdraw. Format needs to be like "10.00"
    currency
    REQUIRED
    string
    The ISO 4217 currency code which applies to all amount values, e.g. approved_amount. SEK or EUR
    site
    REQUIRED
    string
    The name of your site. This will be displayed in the payee's transaction history and during the checkout process.
    bank_account
    OPTIONAL
    string
    Destination bank account number in IBAN format, ie "SE41800008257800XXXXXXXX"
    ref
    OPTIONAL
    string or null
    Merchant's own withdrawal reference.
    account_ref
    OPTIONAL
    string or null
    Merchant's own reference to the User's account.

    KYC info

    A typical kyc response

    {
        "user_id": "9b9047da-175f-d29a-dae8-85b428488c2e",
        "national_identification_number": "19870619-4852",
        "full_name": "Henrik Testperson Testson",
        "first_name": "Henrik Testperson",
        "last_name": "Testson",
        "country_code": "SE",
        "date_of_birth": "1987-06-19",
        "pep": false,
        "address_line_1": "Box 1529 / Prod Utv",
        "address_line_2": null,
        "address_postcode": "17229",
        "address_city": "Sundbyberg",
        "address_country": "Sweden"
    }
    

    kyc_info is the object returned in the deposit flow when asking for KYC information and also found as an sub-object contained in the withdrawal object. It has the following attributes:

    ATTRIBUTE
    full_name string
    The User's full name including given name(s), middle name(s) and last name(s).
    first_name string
    The User's first name.
    last_name string
    The User's last name.
    date_of_birth string
    The User's date of birth in ISO 8601 format.
    pep boolean
    This User is a Politically Exposed Person.
    national_identification_number string
    This User's national identification number.
    Note that the length is 12 digits for SE and 10 for FI
    address_line_1 string
    The User's registered address, first line.
    address_line_2 string or null
    The User's registered address, second line if present.
    country_code string
    Country code compliant to ISO 3166
    user_id string
    The unique ID of the payee.
    address_postcode string
    The User's registered address, postcode.
    address_city string
    The User's registered address, city.
    address_country string
    The User's registered address, country.

    FAQ

    I get a 401 when i try to authenticate. What is wrong?

    Most likely you are using the wrong credentials. If you are unsure if your are using the correct credentials or not, a quick check can be done by going to

    https://api.zimpler.net/v3/payments/

    with your browser and enter the corresponding merchantRef and API keys as user/pwd. If the wrong credentials were used you will get a 401.

    Does Zimpler need to whitelist IPs?

    No we don't.

    Are users checked against any sanction lists?

    Yes. Zimpler checks all users against a number of sanction lists for fraud, terrorism, and money-laundering.

    Who is responsible for verifying the user's payment method?

    Zimpler is responsible for verifying the user's payment method (e.g. payment card). The merchant only needs to ensure the user_id referring to the Zimpler account is correct. The attribute user_id is available on withdrawal object once onDecision javascript function is called.

    How does Zimpler perform the KYC process?

    Zimpler verifies the identity of users with an external identification system. We are a licensed financial institution, and our process is approved by the Swedish financial authority — Finansinspektionen.

    Release Notes

    1.3.1 - National identification number can now be prefilled

    August 2019,
    this locks the string sent by merchant on deposit and login and also reduces input required by customers.

    1.3 - Withdrawal extended

    July 2019,
    withdrawal can accepts Merchant kyc information instead of Zimplers´.

    1.2 - Direct Withdrawal

    February 2019,
    withdrawal can now be done direct to end users from merchant.

    1.1 - Fast KYC

    October 2018,
    added the possibility to get kyc info before deposit authorization is completed.

    1.0 - Zimpler Closed Loop release

    June 2018,
    first release of our deposit and withdraw methods including kyc details both in and out.