​This HowTo shows you how you can create a web service with Dutch payment provider Mollie. We've chosen for Mollie because this is one of the easiest and most used payment providers across our platform. 

Use mollies documentation - available here - next to this documentation for more information on the possibilities and details of the Mollie API.
​

The process of the mollie web service looks like this.

Notice that Mollie only lets you know that there is an update. For security reasons, your app has to request the update itself. Mollie's in-depth explanation is as follows:

The webhook will be called with a single POST-parameter named id. You should use that id to actively fetch the payment to find out about its status. This step seems a little cumbersome but proper security dictates this flow. Since the status is not transmitted in the webhook, fake calls to your webhook will never result in orders being processed without being actually paid.

Now you know the process we're creating with this webservice. Let's go on with the preparation in Mollie.

Before you can develop a web service you'll need an API key. This key authorizes the web service endpoints when making a webservice call. Create an account and website profile on https://www.mollie.com/en/signup When you've created a website profile, Mollie generates API keys for your app.
​Use the test key when developing! 

The API key identifies and authorizes your app, so keep this for yourself. The API key has to be saved in your app to authorize your web service. An API key isn't an Authentication Type in Betty Blocks, because it's nothing more than a single value, which you can simply add to your web service endpoint as a Header variable, which you call Authorization.

When you've got your API key, you can head over to your Betty Blocks app and create a webservice. The host you need is api.mollie.nl/v1/ and the protocol can be set to HTTPS and response content type can be set to JSON (in order to create a custom model later on). That's all for the webservice itself, now we need 2 endpoints.

Add a endpoint to the web service. This will be the endpoint that initiates the payment. The endpoint has to be a POST endpoint and the path is '/payments'.
 This endpoint expects 4 body variables and 1 header. The header variable is the Authorization variable containing your API key. The other four are

The amount of money of the transaction in Euro's
​Description
The description of the transaction is also shown on the bank accounts.

The URL the user has to be sent back to, after making the payment. (notice the capital U in redirectUrl)

 The URL Mollie sends updates to if needed. (notice the capital U in webhookUrl)

Optionally, you could add a variable name method here to define a specific method for the web service. If this variable is not given, the user gets a screen on which he/she can choose one of the available payment methods. For instance, if you give method 'ideal' as a value, the user always has to pay via iDeal; the user won't get a screen to choose another payment method.

After the first endpoint has sent a request. Mollie sends a response back. This response contains a paymentUrl, which is where you've got to send the user to, and a payment identifier, which you need for the next endpoint.
 If you test the webservice, you can create a custom model from the response.

You'll need a second endpoint to ask mollie whether the user's payment has come through correctly. Add a second endpoint, for which the path is  "payments/" + var:payment_identifier. Here you must add payment_identifier as a Path variable. Also, add the Authorization variable as a Header variable and set the Response content type to JSON again. You can now test your endpoints by clicking Run Test at the top right of your screen. If you test the first endpoint with some random data, you can copy the payment-identifier Mollie gives you as input for your second endpoint.

You can create a custom model from this response to use it's data later on. The relevant variables in this response are.

Tells you whether the testing API key was used or the live API key. (Live or Test)

Tells you what the payment status is. Can be either open; canceled; expired; failed; pending; paid; paid out; refunded; charged_back. We advise you to create a list property to save this value on.

If you haven't given a standard payment method in the first request, the user's choice of method is given here.

This is all you need for the web service. Now you can create the web pages for the web service.

You'll need 4 pages (2 GET's 2 POST's) for the whole process.

To enter the amount and description

To process the data and start the payment

The redirectUrl, which has to be given in the first request.

To process webhook updates from Mollie, this is also has to be given in the 1st request.

Your payment action will most likely be on a POST page, so that's what we're going to explain here. The starting point is with a form on a GET-page. This can be a very simple page for this HowTo, as long as it's got 2 input fields. One for the amount and one for the description.
 Make sure this page's form action is set to the first POST page.
 Tip: if you want to create a payment service with only a few payment methods, you can add only the methods you want in a select input in this page.

This will cover the first step in the Mollie-process image provided at the beginning of this article.

The second page is a POST which is called upon when the first page is submitted. This is where most of the magic happens.

You'll have to expect the amount and description here, and create the first request for mollie. In the action of this page, you'll need 3 action-events.

Sending the data to Mollie.

Create a payment in your system based on Mollie's response. (The response is captured in a custom model automatically if you've generated this while creating the web service)

Redirect webpage: redirect the user to the PaymentUrl, provided in Mollie's response.
​

This is where the user will be redirected after the payment process has been completed.
 You should give the user some feedback that his order will be updated once the payment has been updated by Mollie (which usually happens within a couple seconds, but can also take a couple minutes).

The second POST page is called upon by Mollie. Whenever the status of the payment is updated within Mollie, Mollie calls this webhook, which you've defined in the first request.
 Mollie will send a id as an input variable along with the request, so all you've got to do is use this id as input for the Check Payment request and update the corresponding payment status accordingly. You can get the right payment from the backend, by creating a Payment object and filtering on the identifier.

Whenever the webhook POST page is called upon, you should also mail the customer with any updates, but since this isn't necessary for the payment process to work so we haven't implemented it in this article.

You can now test your webservice!

Now you've created a payment web service in your app. Don't forget to change the testing API key to the live API key when you're deploying the web service.

Something not quite clear? Encountered an obstacle that you can't seem to get over? Or do you have some feedback? Don't hesitate to contact us via the Intercom logo at the bottom right of your screen. We'd love to hear your experience with this HowTo!