Earlier IT involvement is the key to simplifying payment integration

David King
David King is CTO at Flywire.

Software integration projects are kind of like the final heist scene in Oceans 11. Every job triggers the next one and is dependent on its perfect execution. Behind it all is lots of concerted and collaborative planning, testing and preparation. Everyone’s job is crucial. But consider for a minute, the changes in that plot if a team of 10 decided to bring in, say, Yen, the acrobat who provides the link between the outside casino world and the inside of the vault, late in the game. The team then assumes Yen would be able to easily find a way to get from the casino and into and around the vault seamlessly. And without some planning and practice doing that spectacular backflip to launch himself from the money carts to the cabinet and clear laser security beams.

You’ll then begin to understand how the CIO often feels.

It’s a film we’ve seen before in our work integrating payment solutions with all major student information systems and ERPs – chief among them Oracle PeopleSoft Campus Solutions, Ellucian Banner and Ellucian Colleague. Ease of integration is sometimes taken by key decision-makers and functional leads as a cue that perhaps busy IT leaders can be brought in later in the process. There are of course strong IT components involved in a payment integration project, and as a result, the phrase “ease of integration” can trigger an uneasy feeling in the minds of IT leaders. But it shouldn’t.

IT leads, when brought in early on, generally come to the consensus after going through integration requirements that the technical list is relatively light. Bringing them in earlier on in the process will mean a faster, more seamless path to completion. Likewise, alignment on priorities at the outset of integration projects can often help drive better, more meaningful conversations between the head of student financial services, for instance, and the IT lead.

Here are three key considerations for CIOs in integrating payment solutions with higher education student information systems or ERP systems.

What’s the footprint required of our environment?

Payment integration requires a footprint on the school’s computing environment. Our core system, for instance, is hosted – but there’s a chunk of code that needs to be dropped into Oracle PeopleSoft so that the two systems can communicate. That’ll obviously require security review, networking and hardware considerations and planning in application lifecycle management. The deep integration can take up to 90 days.

Who do I need on my team to accomplish the payment integration?

Depending on the size and complexity of the institution, integrating a payment solution will require different IT team members. But as a general rule, this project will need:

  • An ERP admin or/and developer
  • A representative from the networking team to set up an additional application server and firewall rules to ensure secure networking and communication
  • A security and identity management team members to do the security review of the code and provide single sign on capabilities

Projects are typically most successful when there is representation from all the functions that the integration will touch – and that could be as many as four to five different people.

How do we maintain it?

On the maintenance end, a dedicated account manager will be in frequent communication with the client’s technology team, informing them about new releases and coordinating and providing support when the school plans a system-wide upgrade. Our releases are backwards compatible, and we push out new functionality monthly. For PeopleSoft, for instance, we just rolled out functionality in the United States that automates access to the 1098-T tuition statement for tax purposes.

When institutions involve IT early when integrating payment solutions with major student information systems and ERPs, it goes a long way in removing the friction from the process and paves the way for productive conversations with other stakeholders.