Are you sure they want you to do that?

I don't mean to be rude or accuse you of anything but that might even count as a phishing attempt if your visitors type their bank login details on a site that does not handle the bank login. Like in real life you would give your grocery store cashier your bank account details and expect him/her to take them to the bank for you.

Couldn't you just offer a link to the bank login instead?

No. There are more realistic reasons why we shouldn't do it, but phishing isn't one of them. This is our front end website, it has always had login fields, and changing it would result in probably tens of thousands of phone calls because it's unexpected. We authenticate our website to our users via EV SSL certificate, which nullifies the phishing argument.

"my provider will not assist with this in any way, shape or form"
>> Did you refer here to the bank platform?

I honestly think that it is really their job to give you the documentation on how to do it. When speaking of banking platforms, in general, you should be very careful with any kind of "manual hacking" of these systems / their forms.

I can clearly see why you want to do that but I'm just really confused from the first message that the banking platform provider isn't assisting you a bit in this (if they are able to allow this)...

I agree with you, they should provide it (especially considering they provided it 4 separate times in the past with our old platform). However, this company has a recent history of considering anything out of the ordinary as "custom work" and they charge an exorbitant amount of money to do anything "custom".

This isn't a "manual hack" in any way. It is simply passing login creds from one site to another. We have 3 additional authentication methods in place beyond userid/password, ranging from geolocation and tokens to third channel verification. We consider userid and password combos to be ineffective forms of authentication and rely on them only to get people to the front door. They want to conduct any transactions, they have to authenticate themselves in another way.

Ok, this was a cost issue, then no problem if you have permission to do this. The first message just seemed quite weird to me in the first place...

I'm not sure whether this will work 100% as you currently have because the banking platform is handling the login in 2 parts and probably carries some session data after the user ID is provided.

An easier solution to me would seem be just to switch your login form to contain the Sign On ID instead and then redirect them to the banking platform to provide their password.

If you want to do it like it is, I still think you'd better to ask them to do this, it is probably just as costly with other 3rdparty developers with testing and debugging etc. especially if you don't have documentation on how to handle the login authentication process.

Getting anything in place is better than a hyperlink. Also, they will not do anything quickly, it'll take them 3-6 months, where as I need this accomplished within 2 weeks.

Ok, that's a bummer that they're not able to help...

The form seems to carry a bunch of validation hashes, so I'm not very confident that this is an easy one to solve without ANY documentation on the system behind.

I think the system behind will just ignore any requests that don't have matching request hashes and I doubt it might even validate that the previous request is coming from the correct domain...

So, all I can say, this is really hard to solve without having any details/documentation on how to solve it. I'd love to help but it just seems that it would be waste of your money and our time trying to solve this one with this information.

Let me see what I can get. I'll let you know.