Experience of implementing Apple Pay mobile payment service in a bank

    In this article, we would like to share our practical experience with the implementation of the Apple Pay mobile payment service, which project approaches we used to solve this difficult task, and what points should be considered if you plan to introduce this service at home.

    We will not go much further into the technical details of the implementation (a separate article will be released a bit later), but if on fingers, then the entire Apple Pay infrastructure consists of the following components that will need to be friends with each other:

    1. The release and life management platform a token cycle (virtual “pseudo” card number) on the side of the payment system. For MasterCard it is called Mastercard Digital Enablement Service (or MDES), for VISA it is called Digital Enablement Program (or VDEP)
    2. Your card processing system
    3. Mobile bank application
    4. The encryption service necessary for transferring data to Apple and the Payment system when binding a card through a mobile bank (in Apple terminology this is called In-app provisioning)

    If item 1 is a boxed solution and has already been developed (only a small adjustment will be required for your card products and specifics), according to claim 2, vendors of processing solutions (for example OpenWay) offer partially or already fully implemented improvements, then paragraph 4 - an encryption service will have to be developed with zero. Be careful about planning and implementing this component, since it took us the most time and effort to debug it).

    On the one hand, the task looks like a classic project (there is a fixed launch time, the end result is clear), so arm yourself with water fall and onward, but on the other hand, implementation speed, quality is very important (why it is important, we will tell you at the end of the article), and the fact that our Bank is now moving everywhere to agile development frameworks (in particular, to Scrum). The result was a hybrid approach, not claiming to be ideal, but suitable for our team during the agile transformation period:

    • The MasterCard and VISA project plan was taken as a reference point (there’s no way to go anywhere, the companies have their own standard project management procedures for which they work they themselves and interact with the outside world)

    • The plan was supplemented by internal work (budgeting and contracting procedures, architecture development, decision approval with information security, internal system refinement, testing, certification, etc.), and completion dates are set in such a way as to reach the desired launch date ( with a margin of 2 weeks, of course). Based on this plan, the need for project team members was identified and this temporary team formed

    • Next, we planned regular confkolls with the whole team (once a week at the beginning of the project, 2 times a week in the middle, and every day for 15 minutes at the final stage before launch), where we took current and future tasks from a large project plan, beat them on sub-tasks, appointed responsible, sent to all this mini-plan (aka the minutes of the meeting) and worked on it until the next conference call.

    • If the project plan “traveled” according to dates, we immediately boldly changed it so that it corresponded to reality and did not make a tragedy out of it

    • As soon as a component was completely ready and tested, it was put out on the battlefield, and after launching the battle for some time we tested the service on a closed group of real users (all of them were bank employees)

    • And so, in small steps moved to the goal.

    If you look closely, you can see some analogies with Scrum events and artifacts:

    • Project plan + specifications of Apple and payment systems - this is a backlog
    • Decomposition of the project plan into sub-tasks for work until the next weekly conference call is PBR and sprint planning, lasting for week
    • Daily konfkolly - daily scrum

    But there were deviations from the frame-Work, in particular, we did not do a retrospective, not tested at the end of each sprint, but when it is already a big part of the component has been developed and integrated to the test howling environment, and we did not have a demo.
    Interestingly, this approach was “born” in the course of work, and was not designed in advance, i.e. Adapted to the details of the team. We hope that this story will inspire you to experiment in the field of project management, and a more flexible approach to achieving goals.

    Why is it so important to implement Apple Pay very high quality? The fact is, before you start commercial operation, you will have to undergo mandatory independent testing (certification) of your solution deployed in battle in one of the 3 test laboratories authorized by Apple. And it will not be easy, the fact is that laboratories are very scrupulous in testing (usually it takes about 2 weeks).

    For example, absolutely all your card designs will be checked for compliance with physical plastic and pictures in your wallet (and if the logo design diverges or the font color does not read well on the phone screen, you will be asked to correct these shortcomings urgently), all possible use cases will be checked, for all supported devices (including iPad Pro 12 ”)), carefully read Terms & Conditions (for example, we were asked to correct punctuation marks in some places). In general, Apple and partners are very careful about the release of products, it will not work to close our eyes to roughness, and you need to be prepared for this in advance.

    So, the work is all done, testing and certification are passed, and the solution is launched. What we have in the balance:

    1. Completed project;
    2. An interesting experience and an unusual approach to solving a project;
    3. Several units in the company that adopted the practices used on the project and continue to use the approach to solving various problems and projects.

    In the next article we will try to tell more technical details and features that you encountered during the implementation of Apple Pay, but for now you can ask questions in the comments.

    Kuzin Sergey, scrum-master of Otkritie Bank

    Also popular now: