Native development vs. iframes: A common integration challenge for credit unions

By DARYL THORNTONCONSTELLATION DIGITAL PARTNERS

So, your credit union has picked a platform that allows you to deliver web-based content. Out of the box, the infrastructure is there to support your primary needs. The foundational resources, connectivity, APIs, etc. are all present in spades. You can imagine how excited your members will be when they get to interact with all the digital tools your team built just for them.

Your credit union hires a team of developers, and they learn the standards, the power of building content for your users on the platform. It’s a goal your credit union has had for a while and it’s finally kicking off. You have the basics covered – users are authenticated, and you’re providing the baseline features they want. Oh no but wait! You have identified a feature that your credit union wants to offer that is currently developed by a third party. Not only have you discovered that the feature is developed by them, but their capabilities showcase solid expertise and far outshine anything your team of developers could develop in the short term. Besides, they have been a great third party to work with from the start.

The discussion starts, and you express how you need the third party to make their digital service available on the platform you picked in order to deliver all your other digital services. They have currently already built web-based content that they have mastered the deployment of. Their standard implementation is an iframe, it allows them to embed their service in any web-based platform with minimum hassle, but because it’s not written for the platform, access to many of the resources is not there, or they require additional integration in order to make it work. Both you and the partner are frustrated because integration is fast, but the limitations don’t let you fulfill the dream or plan.

Read the full article on CU Insight.