Streamlining Customer Payments with Mollie API and Power Automate
Most (B2C) companies like to make payment as easy as possible for their customers (and themselves). Payment providers such as Mollie make this easy by offering familiar payment methods such as iDeal, through an easy to use platform. For companies Mollie offers multiple API’s, such as the Payments API (meant for website integration such as on web shops) and the Payment Links API, meant for creating non-expiring payment links. This blog shows how to use the Payment Links API and Power Automate to create and send payment links to customers, and process after the payment is made.
On a high level, the process will look as follows:
In order to realize this this process, two Cloud Flows are created:
- A Cloud Flow to request a Payment Link, create an email and add the link
- A Cloud Flow to capture when the customer has paid, and process accordingly
Upon registration Mollie supplied two API keys, one for their testing environment to test your integrations, and one for their production environment. We recommend to store the API key in an environment variable. More on that later!
And now for the fun part, how to actually retrieve and send out Mollie Payment Links?
Flow 1: Create and send Mollie Payment Link
1. Configure a trigger – what action will trigger a payment link being sent out? Virtually any trigger can be used, such as manual, when an invoice record is created in Dataverse, when an order is placed.. etc. For demonstration purposes, we create use a “When an Item is Created” trigger using the SharePoint connection.
2. Call Mollie! – The next step is to actually create and receive the payment link from Mollie. To do this, we add an HTTP step, executing an HTTP POST request to the Mollie Payment Links API
- API Key
- Value: The amount of the payment. The API expects 2 decimal places, so €250,- should be entered as ‘250.00’. Note the expression, our input value did not match the exact value format, so we used the expression formatNumber() to make sure it matches.
- Description: shown to the customer on the Mollie Payment Portal. Add for example an order number and the customer’s name.
- Redirect url: The customer is redirected to this url after completing the payment. Consider it the “Thank you” page.
- Webhook url: url is called when the payment status changes. We use this url to trigger a second flow, more on that later!
3. Parse JSON – The response of this action contains an id for the Mollie Payment Link and the actual url of the payment link. In order to make it easy to use these as dynamic content (add the url to an email for example), we parse the response.
In order to create a valid Schema, we recommend the following:
- Running the flow
- Opening the HTTP POST action, and click “Show raw outputs”
3. Copy the entire output
4. Edit your flow
5. Open the Parse JSON step, and click “Generate from sample”
6. Paste your copied output, and click Done!
4. Store Mollie Payment Link ID – In order to later link the payment to a specific order/customer/trigger of the flow, we need to store the id of the Payment Link. In our SharePoint example:
5. Send payment link! – At last, we can send out the payment link. This can be done any way you’d like, for example as an email through a queue in Dynamics CE. In this example we send it out as an email using the Outlook connector. “href” contains the payment link url, used from the Parse JSON
Cloud Flow 2: Capture Payment and process accordingly
1. Trigger – When an HTTP Request is received.
1. Upon saving, the “When an HTTP Request is received” will create a url. The flow will be triggered whenever this url is called. Remember the webhook url in the first flow? We will add the url created in this step flow 2 as the webhook in the HTTP request in flow 1. The result: whenever a customer pays, flow 2 is triggered to process whatever should be processed.
2. Get ID – The HTTP trigger goes off anytime the payment status changes. For security reasons the initial call does not contain payment information other than the Mollie payment link ID. To access the payment information, we need to call the Mollie API again using the payment Link ID, which we’ll extract using a “Compose” action.
The expression used looks like this:
replace(string(triggerBody()), ‘id=’, ”)
The triggerBody() returns as “id={Mollie Payment Link ID}”. To extract just the id itself, we must convert it to a string and remove the “id=” part (replace “id=” with empty string).
3. Call Mollie – Time to call mollie again! A GET request using the ID will return the payment information.
4. Parse JSON – Again, we’ll parse the response to make it easily usable in next actions.
Similarly to in flow 1, to get a valid JSON scheme, run your flow, copy the raw output of your HTTP GET step. Edit your flow, click “Generate from sample” in the Parse JSON step and paste your outputs.
5. Check if customer paid – The flow triggers whenever the status of the payment changes. In order to check if the payment has been made, we’ll add a condition. We know the payment has been fulfilled if the “Paid At” field is populated.
6. Process accordingly – Now you know the customer has paid and have relevant payment information in hand. In the “If Yes” branch of the condition, you can process however fits your business process. In our example, we’ll simply store that the invoice has been paid, the amount paid and the timestamp of the payment. Also, we’ll send a payment confirmation to the customer.
Going Live
In order to change from sending test payments to “live” payments all that has to be done was change the API key. The actual actions to retrieve the payment links and payment statuses, including the url of the API, did not have to be touched, making go-live after testing easy. To make the switch as easy as possible, we recommend storing the API Key in an Environment Variable, so you only have to change the API Key once when migrating, instead of in all the actions where you make a call to the Mollie API.