Changelog

Optimized credential submission UX

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.

Other fixes and improvements

• Upgraded the application creation flow that occurs when a new user signs up on the Dev Portal. Applications will be ready to use faster as we've moved some of the time consuming resource generation to take place asynchronously.
• Improved security in the email verification flow upon registration
• The Mockbanks have been updated to reflect the change inn balance immediately after a payment has been initiated
• Increased the number of bank specific error codes that users see upon failed connections and payments. This means your user is more likely to know what went wrong and therefore be able to fix it when trying again.
• Fixed an issue that caused failures upon payment source creation when users had a beneficiary with the same nickname but a different IBAN in their bank's beneficiary book
• Multiple improvements which improve stability, reduce latency, and fix bugs

Filter your payments logs

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!

Other fixes and improvements

• In the sandbox environment, if you set the payment amount to 34.56, the payment will fail. This should allow you to ensure that your flow handles the scenarios where a payment fails.
• When trying to retrieve a previously deleted payment source or entity, you will now receive a 404 RESOURCE_NOT_FOUND type error rather than a 400 BAD_PARAMETERS
• More banks supporting USD Payments
• Link SDK will tell the user if their device disconnects from the internet
• Link SDK shows the user a small banner if a balance update fails in the "Select Payment Source" view
• Link SDK now instructs the user if a connection to the bank fails because a user has logged into their account elsewhere
• On the Dev Portal, you can now access the detail view of a payment directly from the billing list view
• The Dev Portal has fixed an issue where pressing the back button after exiting a payments detail view didn't show payments detail

Filter your data logs

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!

Other fixes and improvements

• New Lean applications can now immediately start developing with the payments API. For existing users this means you can create new applications without asking someone at Lean to enable your payments capabilities
• More banks now support USD payments, you can find out which ones by calling our /banks endpoint
• Link SDK shows the support ticket number more prominently in error screens
• Link SDK shows the payment destination display name rather than the application name when asking for payment confirmation
• Link SDK performs front end validation on username and password forms, matching bank specific validation
• Link SDK titles have been changed in the opening screens for the Create Payment Source and Link flows to be more descriptive of the action
• Link SDK explicitly asks for permissions related to payment initiation and beneficiary creation in the Create Payment Source flow
• Link SDK - Instructions to guide users with Secure Key code generation have been edited to be clearer

(Even more) webhook security

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.

More realistic Mock Bank data

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.

Endpoint to retrieve a single entity

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.

Other fixes and improvements

• More banks supporting USD Payments!
• Link SDK alerts users when their internet connection has dropped
• Link SDK blocks users from clicking on payment sources when the balance is updating
• Link SDK detects the exact reason for more payment and connection rejections and tells the user what went wrong and how to fix it. Examples include users who are locked out of their bank accounts, users who have surpassed their daily payment limit with their bank, and users trying to make bank payments through credit card accounts
• Link SDK now triggers a callback upon receiving an error
• When asking for the OTP, the Link SDK now shows the user the text they are inputting
• More specific error messaging when incorrect parameters are provided on data calls
• Bank identifiers added to the detail page of data logs on the dev portal
• Various bug improvements which contribute to the stability of the dev portal
• Multiple bug fixes and internal platform upgrades

Assign payment destinations to customers

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.

USD Payments

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.

Other fixes and improvements

• Your customers are now warned when OTPs are expiring soon
• You can search payment destinations by owner type
• Link SDK now has a dedicated view for payments that are marked as pending by the bank
• Link SDK now has an updatePaymentSource() function which allows you to add new payment destinations as beneficiaries to an existing payment source
• Link SDK will now show an ID on failed connections or payments to allow easier referencing in customer support interactions
• Multiple bug fixes

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.

Payment destinations - initiate payments to ANY bank account

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.

Status page

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.

Transaction References

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.

Other fixes and improvements

• We now have 2 mock banks in the sandbox environment! This should make it easier for you to see what it looks like when your customers connect multiple accounts for data or payments.
• The "Payments" section on the developer portal now has details for each payment such as the transaction reference returned to us by the bank and the payment_intent_id for each payment.
• We now give your customers more detailed error messages when banks reject connections or payments rather than a generic failure message.
• Fixed the message the Link SDK returns on close to the TPP callback to be specific for each success type, eg “Payment completed” or “Entity reconnected”.
• LinkSDK screens will now display an identifier in case of failures which you can send to us when you're logging support incidents.
• Speaking of support incidents, we have a new help desk for all our customers (https://devsupport.leantech.me). You can use this portal to report any issues and then monitor the status of them as we go about identifying and fixing the issue. As always, you can also report any issues by emailing devsupport@leantech.me
• Multiple bug fixes.