New updates and improvements to Lean's platform.
Subscribe for updates:
Till now, we would set the transaction reference as the payment intent id, without the hyphens. We've just made an update that allows you to configure the transaction reference yourself by using the description parameter when creating a payment intent. You can use this to enhance your reconciliation efforts by controlling what you will see when the payment sppears on your bank's transaction statements. Please note that it is dependent on the sending and receiving bank whether the transaction reference shows at all.
The Developer Portal now has complete support for separate Production and Sandbox applications within a single account. You are now able to completely mimic services across your UAT and Production environments, without worrying about cross-contamination of your data. This includes being able to set up separate webhook endpoints, keys, data and payment logs for each environment.
International Payments are now live with select banks across the Lean platform. This means your customers in the UAE can send payments to Saudi Arabia, Egypt, Pakistan, India, Bahrain, Kuwait, Oman, USA, Canada, Mexico, UK, Cayman Islands, Seychelles, Germany, France and Switzerland. All with the same ease and simplicity of local domestic transfers.
To take advantage of international payments, you will need to add an international Payment Destination - the rest is handled by the LinkSDK as normal.
You can now create a single sign on for your users to start using Lean's Data and Payment API's. LinkSDK's new .connect() method allows you to generate a Payment Source and an Entity at the same time, allowing you to combine both Data and Payments for your services without any added friction.
connect() is currently available from the following versions of the LinkSDK: Web SDK - 1.14.4 iOS SDK - 1.0.6 Android SDK - 2.1.2
Validation, specific error reporting, and step by step instructions — these were the ingredients chosen by our product team to maximise the conversion of your customers submitting their credentials during the Create Payment Source and Link flows.
We've first applied front end validation on the credential submission view that matches the specific validation for usernames and passwords set by each individual financial institution. This will immediately alert your customer if they've entered invalid credentials. This shortened feedback loop will increase the probability of an eventual conversion.
We've also enhanced the error messages when a bank rejects a connection after the customer submits their credentials. Your user now receives specific reasons explaining why the connection was rejected and instructions on what to do differently to successfully connect.
Finally, we've included detailed instructions specific to each financial institution about how and where to find the necessary details to connect their bank accounts. These instructions are accessible within the credential submission view.
We've already noticed a small yet statistically significant increase in the conversion rate of customers who land on the credential submission view to those who end up connecting their financial institution account successfully.
The totally unexpected sequel from last changelog's filtering of data logs! You can now filter your payments by date, amount, customer_id, and status to make debugging, reporting, and reconciliation even easier. Let us know if there are more ways you'd like to filter your payments and we'll add it to our roadmap!
Looking for something specific within your data calls? We've got you covered. You can now filter your data logs by customer_id, endpoint, response status, and date. You can use this for debugging, customer service, or analytical purposes. Similar filtering for the payments logs are coming soon!
Till now you could verify the source of our webhooks but whitelisting our IP or using mTLS, but we love finding ways to make Lean even more secure. If you inspect the headers sent with our webhooks, you'll now see a
lean-signature with a value that begins with "sha512=".
This is a hash-based message authentication code (HMAC) which was constructed by using SHA-512 as the message digest algorithm and your "webhook secret" as the shared secret key to hash the webhook body.
Your "webhook secret" can be found in the Authentication section of the developer portal. By creating this HMAC yourself and comparing it with the value of the
lean-signature header, you can ensure that the webhook you received came from Lean and nobody else.
We've added more realistic transactions patterns to the accounts within our Mockbank. Your test users will now have transactions that more closely resemble a real person. Each test user has been programmed to make between 0 and 8 transactions per day. Additionally, none of the accounts will start off with negative balances.
We've implemented an endpoint to retrieve a single entity for a given customers. This means you can stop looping through all entities for a customer to find out which bank an entity belongs to! The documentation for this endpoint is here.
You can now provide an optional
customer_id when creating a
payment_destination to easily associate payment destinations with the customers who own them. We've added a corresponding GET request to fetch all payment destinations for a customer.
We now allow you to initiate USD denominated payments with certain banks. USD payments can be made from any account within the bank, irrespective of the account's primary currency. As always you will be able to test this functionality with our mockbank.
Welcome to our first public changelog. We'll be sending these after every major release letting you know of all the new features, improvements, and fixes we've pushed to our platform.
Until now, all payments made by you had to go to the same, predetermined bank account. Not anymore. You can now decide where each individual payment should go. Whether you enable your customers to send transfers to each other, or implement custom business logic to configure which of your company's bank accounts a payment should go to, the decision is in your hands.
You can now go to https://status.leantech.me to check the status of our APIs, SDKs, and our Developer Portal. In the future, we'll be adding statuses for each of the financial institutions we offer and notifying you of all changes to statuses via webhooks.
We're now storing the transaction reference codes that banks assign to payments and sending them with the webhooks we send to let you know a payment has been made. You'll also be able to see these transaction references when you query for payment details on our API and on the "Payments" section of our developer portal.
payment_intent_idfor each payment.