Experience in implementing Apple Pay mobile payment service in a bank
In this article, we would like to share our practical experience in the implementation of Apple Pay mobile payment service, which project approaches we used to solve this difficult task, and what points need to be taken into account if you are planning to implement this service at home.
We will not go much further into the technical details of the implementation (a separate article will be published a little later), but if on the fingers, the entire Apple Pay infrastructure consists of the following components that will need to be friends with each other:
1. Platform for issuing and managing the life cycle of a token (virtual “pseudo” card number) on the side of the payment system. In MasterCard, it is called the Mastercard Digital Enablement Service (or MDES), in VISA it is called the Digital Enablement Program (or VDEP)
2. Your card processing system
3. Mobile banking application
4. The encryption service required to transfer data to Apple and the Payment System when linking 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 is required for your card products and specifics), according to claim 2, processing solutions vendors (for example, OpenWay) offer partially or already fully implemented improvements, then item 4 is an encryption service will have to develop from scratch. Take a close look at the planning and implementation of 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 date, the end result is understandable), so arm with water fall and go ahead, but on the other hand, the speed of implementation, quality (why it is important, tell at the end of the article), and the fact that our Bank is now everywhere moving to agile development frame-work (in particular, to Scrum). The result was a hybrid approach that does not claim to be ideal, but which approached our team during the agile-transformation period:
• The MasterCard and VISA project plan was taken as a point of reference (there’s no way out of it, companies have their own standard procedures for managing projects on which they work and interact with the outside world)
• The plan was supplemented with internal work (Budgeting and contracting procedures, architecture development, decision approval with Information security, internal systems refinement, testing, certification, etc.), and completion dates are stamped 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 was formed.
• Next, we planned regular conflicts 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 launching), where they took current and future tasks from a large project plan, beat them they assigned responsible persons to the sub-tasks, sent this mini-plan to everyone (he’s the minutes of the meeting) and worked on it until the next conference.
• If the project plan “rode” on dates, we immediately boldly changed it to match the reality, and did not make a tragedy out of it
• As soon as this or that component was fully prepared and tested, it was taken out to the combat environment, and after withdrawal to the battle for some time they tested the service on a closed group of real users (all these were bank employees)
• And so, in small steps, moving towards the goal.
If you look closely, you can see some analogies with Scrum events and artifacts:
• Project Plan + Apple and Payment System Specs are backlog
• Decomposition of a project plan into sub-tasks for work until the next weekly conference. This is PBR and sprint planning for a week
• Daily confcolla - daily scrum
But there were deviations from the frame wag, in particular, we didn’t do retrospectives, we tested not at the end of each sprint, but when most of the components were already developed and integrated on the test environment, and we didn’t have a demo.
Interestingly, this approach was “born” in the course of work, and was not designed in advance, i.e. adjusted 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 achieve goals.
Why is it so important to implement Apple Pay very high quality? The fact is, before launching into commercial operation, you will have to undergo mandatory independent testing (certification) of your solution deployed in combat in one of the 3 test laboratories authorized by Apple. And it will not be easy, the fact is that laboratories are very meticulous 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 the wallet (and if the design of the logo diverges or the font color is hard to read on the phone screen, you will be asked to eliminate these shortcomings immediately), all possible use cases will be checked, for all supported devices (including iPad Pro 12 ”)), carefully read by Terms & Conditions (for example, we were asked to correct punctuation marks in some places). In general, Apple and partners are very attentive to the release of products, close eyes on the roughness will not work, and this should be prepared in advance.
So, all the work is done, testing and certification passed, and the solution is launched. What we have in the rest:
1. Completed project;
2. An interesting experience and an unusual approach to the solution of the project;
3. Several units in the company that have adopted the practices used in the project and continue to use an 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
We will not go much further into the technical details of the implementation (a separate article will be published a little later), but if on the fingers, the entire Apple Pay infrastructure consists of the following components that will need to be friends with each other:
1. Platform for issuing and managing the life cycle of a token (virtual “pseudo” card number) on the side of the payment system. In MasterCard, it is called the Mastercard Digital Enablement Service (or MDES), in VISA it is called the Digital Enablement Program (or VDEP)
2. Your card processing system
3. Mobile banking application
4. The encryption service required to transfer data to Apple and the Payment System when linking 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 is required for your card products and specifics), according to claim 2, processing solutions vendors (for example, OpenWay) offer partially or already fully implemented improvements, then item 4 is an encryption service will have to develop from scratch. Take a close look at the planning and implementation of 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 date, the end result is understandable), so arm with water fall and go ahead, but on the other hand, the speed of implementation, quality (why it is important, tell at the end of the article), and the fact that our Bank is now everywhere moving to agile development frame-work (in particular, to Scrum). The result was a hybrid approach that does not claim to be ideal, but which approached our team during the agile-transformation period:
• The MasterCard and VISA project plan was taken as a point of reference (there’s no way out of it, companies have their own standard procedures for managing projects on which they work and interact with the outside world)
• The plan was supplemented with internal work (Budgeting and contracting procedures, architecture development, decision approval with Information security, internal systems refinement, testing, certification, etc.), and completion dates are stamped 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 was formed.
• Next, we planned regular conflicts 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 launching), where they took current and future tasks from a large project plan, beat them they assigned responsible persons to the sub-tasks, sent this mini-plan to everyone (he’s the minutes of the meeting) and worked on it until the next conference.
• If the project plan “rode” on dates, we immediately boldly changed it to match the reality, and did not make a tragedy out of it
• As soon as this or that component was fully prepared and tested, it was taken out to the combat environment, and after withdrawal to the battle for some time they tested the service on a closed group of real users (all these were bank employees)
• And so, in small steps, moving towards the goal.
If you look closely, you can see some analogies with Scrum events and artifacts:
• Project Plan + Apple and Payment System Specs are backlog
• Decomposition of a project plan into sub-tasks for work until the next weekly conference. This is PBR and sprint planning for a week
• Daily confcolla - daily scrum
But there were deviations from the frame wag, in particular, we didn’t do retrospectives, we tested not at the end of each sprint, but when most of the components were already developed and integrated on the test environment, and we didn’t have a demo.
Interestingly, this approach was “born” in the course of work, and was not designed in advance, i.e. adjusted 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 achieve goals.
Why is it so important to implement Apple Pay very high quality? The fact is, before launching into commercial operation, you will have to undergo mandatory independent testing (certification) of your solution deployed in combat in one of the 3 test laboratories authorized by Apple. And it will not be easy, the fact is that laboratories are very meticulous 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 the wallet (and if the design of the logo diverges or the font color is hard to read on the phone screen, you will be asked to eliminate these shortcomings immediately), all possible use cases will be checked, for all supported devices (including iPad Pro 12 ”)), carefully read by Terms & Conditions (for example, we were asked to correct punctuation marks in some places). In general, Apple and partners are very attentive to the release of products, close eyes on the roughness will not work, and this should be prepared in advance.
So, all the work is done, testing and certification passed, and the solution is launched. What we have in the rest:
1. Completed project;
2. An interesting experience and an unusual approach to the solution of the project;
3. Several units in the company that have adopted the practices used in the project and continue to use an 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
Source: https://habr.com/ru/post/332946/
All Articles