Mastercard: Loyalty Program
The Mastercard Loyalty Rewards program is a suite of integrated loyalty solutions with end-to-end support services, that enables Merchants and Issuers to create customised loyalty and rewards programs for their customers.
“At Mastercard, our brand has long been defined by experiences... Through products like Pay with Rewards, we enable choice for cardholders to spend their points and miles anywhere, anytime where Mastercard is accepted. Through Mastercard Travel & Lifestyle Services, we also provide best-in-class travel planning and booking services, bringing cardholders simple, high value digital solutions.”
As an end-to-end partner, they rely on technology to create these personalised digital distribution channels, and being able to deliver quickly and safely into production.
During the application build phase, there were two teams - the Loyalty Web Team and the (REST) Loyalty API Team. Any changes to the API specifications of one of these services could potentially break the system. Prior to development, each team would collaborate with the various API teams to agree on the API specification. However, during development, there were often discrepancies between the expected and actual implementation of these APIs. When the discrepancies weren't identified early on, the resulting rework resulted in delays and increased cost of the initiative.
Mastercard chose Pact to identify these issues earlier in their development process (aka "shift left"), reduce the cost of integration testing, and increase velocity of the teams.
By using consumer-driven contracts with Pact, the Mastercard Loyalty team alleviated the problem of API specification drift helping teams guarantee that the API specifications were correct at development time, instead of later in the lifecycle - a "shift left" in the feedback loop. Mastercard's web application and API development teams were now able to:
- integrate contract testing into their CI/CD pipelines, streamlining API testing and reducing feedback time
- work in parallel, enabling them to move faster
- release independently, enabling teams to scale
- prevent breaking changes from being released to production
The Government Digital Service team is responsible for the digital transformation of the UK Government. One of the services they provide is their Pay platform, which enables other departments to take and manage payments on a fully PCI and government standards compliant platform.
Previously, to release a change, they used to run end-to-end tests to verify the entire system. This meant spinning up their microservices architecture in a dockerized environment to run tests. They found that doing it this way was:
- resource intensive
- not giving them the benefits of moving to a microservice architecture as they were still testing as a distributed monolith
By switching to contract testing we now have confidence that any service we deploy will always be compatible with the things it needs to connect with
- only use end-to-end tests for new functionality when it is unavoidable
- are confident deployments will not introduce breaking changes between services
- are in a position to replace expensive end-to-end testing with Pact testing where applicable
Atlassian is an enterprise software company that develops products for software development, project management, and content management. It is best known for its issue tracking application, Jira, and its team collaboration and wiki product, Confluence.
One of the reasons Jira is so successful is its deep integration with other tools - and to achieve this, the Jira team builds integrations - "A lot of integrations". In a recent change, they've re-architected parts of their platform to move aware from pulling in data from external vendors to having external vendors push data to them, resulting in an increase in the number of APIs they were required to design and build. Their first objective was to implement their new feature flag integration in Jira.
The project had a tight deadline (8 weeks), external customers, and a lot of "unknown unknowns":
These constraints led us to one overarching driver: we needed to move quickly, and iterate on our API fast as we received feedback from our external customers.
The current approach to designing, building and releasing APIs had two big drawbacks:
- Slow feedback loops – Time from “start design” to “get feedback” was measured in days or weeks.
- Breaking API changes – It was too easy to introduce unintentional breaking changes to APIs during maintenance, unless there was a strict discipline in place to detect it.
The team moved to a specification-first approach, meaning APIs were documented, codified in tests and shared with all parties. To achieve this, they used a number of tools including Swagger / OpenAPI (OAS) specification and Pact.
- Iterative API design – Feedback on the API design was fast and meaningful.
- Parallel development – Integration teams could begin implementation on their side without needing to wait for the API implementation to complete.
- Shorter feedback loops – Teams were able to get internal or external feedback within hours, not days.
- Automated mocks – Teams could build mocks from the Swagger and Pact definitions without fear that it would fail when it came time to test the real implementation.
- Contract testing for safety – They received immediate feedback in their tests when a breaking change was about to be made to the API implementation by validating against our API spec.