Apple pay
This is a template that should be used to document each feature. It’s meant to be easy, not prescriptive - change it at will!
Table of contents
- 1 Table of contents
- 2 Definition
- 3 Open questions
- 4 Requirements
- 4.1 Problem statement
- 4.2 Acceptance criteria
- 4.3 Success metrics
- 4.4 Assumptions
- 5 Solution
- 5.1 Scenarios
- 5.1.1 Scenario 1: xxx
- 5.2 Design
- 5.1 Scenarios
- 6 Development
- 7 Release
Definition
Status | NOT STARTED IN DESIGN IN DEVELOPMENT COMPLETED |
RBIberia Owner |
|
RBI Owner |
|
Open questions
We need to constantly make this section empty.
Requirements
The Apple Pay SDK is successfully integrated into both the web and app platforms.
The payment flow is implemented according to WL standards
It will be embedded in the WL, not using Paycomet iFrame.
The integration complies with the latest version of Apple Pay APIs.
A clear and intuitive Apple Pay button is present on the checkout page of both web and app interfaces.
The Apple Pay button aligns with the overall design and branding of your platforms.
Apple Pay integration is tested on various devices and browsers (for web) and iOS versions (for the app) to ensure compatibility.
Proper error messages are displayed to users in case of payment failures or issues.
Clear instructions are provided on how users can resolve common payment-related problems.
Page load times and transaction processing times are within acceptable limits.
Problem statement
Acceptance criteria
Success metrics
Assumptions
Solution
Scenarios
Note: these are high-level scenarios that must pass testing before we can release the feature. They should also be used to drive design. Note that we do not specify user interface details in these steps - that is deliberate so that we focus on the process and not on the UI since the UI can change throughout design and development.
Scenario 1: xxx
Steps | Expected results |
---|---|
Do this | Expect that |
Design
Figma design here: [insert link]
Development
Release