What’s BNPL?
Buy Now, Pay Later (BNPL) is a type of short-term financing that allows customers buy a product and pay for it at a later date in monthly installments. It’s usually a faster and easier way to buy items on credit without having to wait on an actual loan.
To approve use of this service, providers of Buy Now, Pay Later products have to assess the customer’s ability to pay back in full and on time. This includes knowing the user’s income level, weighing that information against the criteria to get the particular item on credit and then automatically approving or rejecting the customer’s application.
Usually, all or some of these processes are tied together with code and then rendered on a mobile app or website that the user gets to interact with. For our build, we’ll be using none of this.
What we’re building
We’re building a BNPL product for an imaginary company called Furnish - yes you guessed it, a furniture company. Furnish sells beautiful furniture pieces to millennials and they’ve decided they want their customers to be able to buy their favorite pieces and pay for it later in installments.
For this to work, Furnish has to access bank statements of their customers and approve orders of those whose average monthly income matches the criteria that has been set - which is an average of at least 20,000 Naira. To make things easy, we’ll ditch website and mobile app builders and settle for a simple form for the user interface.
Toolstack
The tools we are going to be using are:
- Make (formerly known as Integromat)
How it works
A customer makes an order through a form, submits their bank statement through Mono and then receives an email notification letting them know if their order was approved or rejected.
Checklist
Create an order form on Tally form
Create a Table in Airtable
Link form submissions in Tally to Airtable
Create a statement page in Mono
Build out the automation in Make
Let’s Build
Create an order form in Tally
Start by creating an order form in Tally. Instead of a mobile app or website, this is going to be what a customer interacts with. It keeps this build simple but you could always replicate with an actual site.
For the form, we’ll just collect some details that we need like the name (Make sure this is in upper case) and email of the customer, what furniture they want to buy on credit and their shipping address.
I’ve built a template that you can copy, get it here. Pictures and names of the furniture pieces in the form are all gotten from Taeillo.
Create a database in Airtable
Airtable is great for storing data and collaborating. It’s like Google Sheets but cooler, at least in my opinion. We’re going to use this to keep the details of customers, which is all the information requested in the order form and some additional things like order status , account id (we’ll get to this in a bit) and average monthly income. You can copy the base here.
Link form submissions in Tally to your Airtable base
Next, we are going to automate recording responses from our order form to Airtable. You can do this with Zapier or Make but the guys at Tally have simplified this so you can link your form directly from your dashboard.
Select your form from your dashboard and head over to Integrations
Search for the Airtable integration and click on Connect
Follow the instructions to connect your accounts on the popup page: Add your API key, App ID and Table name. Also, make sure you map the fields on Tally and Airtable correctly.
If you did all of that correctly, you should see this
Create a statement page in Mono
To create a statement page on Mono, you’ll need to first create an app on your dashboard. Once you’ve done that, you can go ahead to create a statement page.
Next, copy the link of your statement page from your Mono dashboard.
Head over to the settings of your form on Tally, toggle on the ‘Redirect on completion’ option, paste the link and save.
Now when a customer submits an order through the form, they’ll be redirected to the statement page. Make sure that you test the form to be sure it works:
Check that it redirects to the Mono statement page after a response is submitted
Check that the response submitted in the form matches what is in the database on Airtable
Build out the automation in Make
This is the final and longest step of the entire build so you might want to take a little break if you’re building. But before we start, a little explanation.
Normally, to connect a user’s bank account in Mono, you would use the Connect Widget. This requires some code that when run would pop up the widget on your mobile app or website and when the user connects their bank account, the code on the backend would return a unique account id tied to that user’s connected bank account.
This unique id is what you would then store in a database and use to call the API to get details such as the income, identity, transaction, assets etc. of that particular user.
But we’re not using code so we can’t get the unique account id of users that way. What we can do, is make use of Auth (Connection) webhook event in Mono. This event fires when a user connects their account successfully and returns the unique id tied to the bank account connected.
Using Make, we’ll be able to set a webhook URL that receives this data and stores it in our Airtable database so we can use it to call the API to get the monthly income of users.
Let’s jump into it.
PART A
First, sign up or log in to Make and create a new scenario.
Click on the purple plus icon, search for Webhooks and select it.
Next, you’ll see a list of the triggers and actions for Webhooks, click on the trigger labelled custom webhook.
When you select the custom webhook trigger, you’ll see the option to add a new webhook. Click on it, name the webhook and save.
Make will generate a unique webhook link for you, just go ahead and copy it.
Now go back to your Mono dashboard, select the app that you created and click on add webhook.
Paste the webhook link you copied from Make and save.
We’re not done yet but we’re almost there😊.
PART B
You need to test that the webhook actually works so connect your bank account through the statement page that was created. Once you’ve done that, you’ll see on Make that the data has been successfully determined.
Right click on the Webhook module and select ‘Run this module only’.
After the module finishes running, you should see a green checkmark beside the Webhook text and a search icon at the top right of the module. Click on the search icon and expand the output.
If the module keeps running or isn’t successful, try connecting your account one more time and run it again.
I had previously connected one of my accounts to test which is why the event on my end reads as ‘mono.events.account_updated’. For newly connected accounts, the event name would be ‘mono.events.account_connected’.
Either way, you get the unique account id of the user’s connected bank account.
PART C
Next, we’re going to use the id to call the account details and income API. You can find Mono’s API documentation here. We’ll do this using the HTTP module in Make which makes it easy to run API requests from inside the automation tool.
Search for the HTTP module and add it.
Choose the ‘Make a request’ action.
Enter the URL for the account details endpoint: https://api.withmono.com/accounts/{id} where {id} is substituted for the id value we got from the webhook module.
It would look like this:
Choose GET as the method and click on ‘Add a header’.
Put ‘mono-sec-key’ as the name and your live secret key as the value.
Select ‘Raw’ for the body type, JSON for the content type and yes for the option to parse the response.
Do the same for the income endpoint but change the URL to https://api.withmono.com/v1/accounts/{id}/income where {id} is substituted for the id gotten from the webhook.
You can connect your account through the statement page again to run the entire scenario and test again. If the test is successful, you should see this:
The status code for both requests should be 200. The account details endpoint will return the bank account details of the user while the income endpoint will return the average monthly income for that account in kobo.
PART D
The final part of this step (Yes, we’re almost done. Great job getting this far!) is to update the records of the user in Airtable with the account id and their average monthly income. Then send them an email to let them know if their order was approved or rejected. You may have to connect your account again to test.
First thing we’re going to do is search for the user on our Airtable base. Add the Airtable module to your scenario, select the ‘Search for a record’ action and connect your Airtable account by following the steps provided.
Set up the module by selecting the appropriate base and table. Set the limit to 1, the view to grid view and add this to the formula field: (Name)=(”Name of the user gotten from the first HTTP module”)
Run the Airtable module and expand it. If successful, the results should show all the details of the user’s record in Airtable as well as the ID of the record which we’ll need in the next step.
Create another Airtable module and choose the ‘Update a record’ action. Connect your table and base just like before, when you’ve done that, you’ll be able to add new data that you want the details in the record to be updated to.
First, add the record ID from the previous step.
Then scroll down to find the account id and monthly income field. Remember these are the two things we need to update.
Add the account id gotten from the webhook module we ran at the beginning to the field.
Also add the average monthly income gotten from the second HTTP module to the monthly income field.
Then run the module. If it is successful, you should see all the details of the record including the account id and monthly income.
For the email notification, you can do this in either of two ways:
- Add another module connecting your preferred email tool and then a final module to update the record on Airtable. This way, the email will be sent if the criteria is met and then the order status of the record updated to ‘Approved’.
- Add the final module to update the record in Airtable, then set up the ‘Send email’ automation inside your Airtable base without needing to connect an email tool. This way, when the criteria is met, the status of the record would be updated to ‘Approved’ and the automation in Airtable will fire off, sending the approval email.
We’ll use the second option.
Set up another Airtable module with the ‘Update a record action’ like you did here but in this case you’ll be updating the order status field. Type the word ‘Approved’ in the field and save.
Next click on the tool icon between the last two modules of the scenario and select ‘Set up a filter’.
Label the filter and proceed to set up the condition. Select the monthly income value from the previous module and divide by 100 using the Math Functions.
We’re dividing by 100 because the average monthly income we got from Mono is in Kobo.
Change ‘Equal to’ to ‘Greater than’ and type 20000 in the second field.
Go to Airtable and click on the ‘Automation’ option at the upper right side of the base. Then select the option to create a custom automation.
Give the automation a name and select the trigger as ‘When a record matches conditions’.
Choose the correct table and set the condition as it is in the picture.
To test, set a record’s order status to ‘Approved’ and the results will let you know if it was successful or not.
Choose the ‘Send email’ action and configure it. Set the label, subject line, body of the email and recipient.
To choose the recipient and reference any other information in the record e.g. the name of the furniture, full name of the customer etc., use the blue plus sign.
Preview your email, turn the automation on and save.
And that’s it!
You can create another filter where the order status is updated to ‘Rejected’ if the average monthly income is less than 20,000 Naira. Then create another automation in Airtable with the condition of the order status set to ‘Rejected’ and a different email body.
Testing
Now that you’re done building, it’s time to test everything. The good thing about testing in bits as you build is that you’re able to spot mistakes easily and fix the problem.
I ran the automation once and it was successful. Yay!
I also got the email right away.
And that’s the end of our build.
You can also use this automation for other different use-cases.
Extensions and other use-cases
Extensions
- Delivery : You could automate the shipment and delivery of the furniture so that once the customer gets that email, the delivery service provider also gets notified so that the furniture is picked up from you and delivered to the customer’s shipping address. You could use the Sendbox API for this.
- Repayment: Paystack’s subscription feature could help to facilitate repayments. You could create a subscription with the repayment amount and duration through the API, setting the customer’s order to pending until they subscribe to the plan after which the record will be updated to Approved. This way, their card will be debited for the full repayment amount every month.
Other use-cases
- Rent Now, Pay Later: This is pretty much the same case but for renters so you may want to get some additional information and set the criteria based on that.
- Lending: As a business or an individual lending money to people, this could be a helpful automation. For example, if your funds for lending are inside your Paystack account, you could run this automation with an additional HTTP module to transfer funds via Paystack API when the user’s request has been approved.
If you liked this article, make sure to share it with someone.
If you’d like to leave feedback, you can tweet at me or send a DM.
Need help with the build or anything no-code related? Send an email.