mobilabsolutions/stash-sdk-android

Android code and documentation for the Stash! SDK

stash-sdk-android's Issues

Create wiki page for android architecture

• Add page to wiki describing architecture and decisions made in detail

Acceptance criteria

• (Obviously) Wiki page is created and describes architecture

Clean up dependencies.

Remove Payment Manager from SDK code and documentation

User story:

As a merchant I am concerned that a malicious customer will be able to change the amount that needs to paid before sending a payment request. I also don't want to verify each request for the validity. To remove the possibility of a fraud I would like the payment from mobile option to be removed

Implementation overview

We need to delete Payment manager and relevant implementations, as well as update the documentation to reflect the changes

Acceptance criteria:

• Payment manager is removed
• Documentation is updated
• Payment tests are removed

Implement Adyen UI module

User story:

As a SDK developer I want to offer prepared UI for Adyen so that merchants using it can use our SDK easily.

Implementation overview

• Implement the credit card registration UI.
• Implement the SEPA registration UI.
• Implement the support for PayPal UI flow.

Acceptance criteria:

• UIs are implemented and working correctly.
• Tests are written and run successfully.
• Documentation is written.

Discuss with the designers the UI customisation

User Story

As a SDK developer I need to know which customisation options to provide in my API.

Acceptance Criteria

• The agreement is reached.
• Documentation is written.

Improve the sample App to become a Demo App

User story:

As a sales lead I need a nice demo app that I can show to potential customers.

Implementation overview

• Implement the improved UI
• Implement the list of mocked items screen

Acceptance criteria:

• The new UIs are implemented.
• The App is working.

Modularize PSP integrations

User story:

As a developer I would like to have PSP integrations in separate modules, so I can choose exactly the integrations I need, and keep the complexity and size of my application lower

Implementation overview

To do this we should create a sample integration module, so it's clear how new integrations should be implemented, as well as implement a system to discover which integrations are available at runtime, and use them correctly

Acceptance criteria:

• A sample integration module is created
• Current integrations are moved to modules
• Documentation is updated to reflect how to implement integration

Implement Adyen registration flows

User story:

As a SDK developer I need to implement the CC and SEPA registration flows to support the alias registration for Adyen.

Implementation overview

• Implement the CC and SEPA registration flows.

Acceptance criteria:

• The CC and SEPA registration is implemented,
• Tests are written and pass successfully,
• Documentation is written.

Update the existing PSP modules to use the new backend API

User story:

As a mobile SDK developer I need to update my modules so they continue to work properly with specific PSPs.

Implementation overview

• Update the module to call new MobiLab backend handler.

Acceptance criteria:

• Implementation is updated
• All tests work fine
• Documentation is updated to reflect how to implement integration

Implement the JWT alias handling

User story:

As a SDK developer I need to handle responses from the MobiLab backend correctly so that I can use the JWT alias to perform payment methods registration.

Implementation overview

Add JWT handling library, model the JWT alias into a proper Kotlin object and document and expose it in the API.

Acceptance criteria:

• JWT alias can be used
• Documentation is added
• Tests are written and passing

PayPal payment method integration

User story:

As a merchant I would like to use PayPal to process my payments.

Implementation overview:

• Integrate the PayPal SDK.
• Show PayPal UI when requested.
• Backend createURL for PayPal is integrated.

Acceptance criteria:

• PayPal payments can be executed.
• Tests are written and run successfully.
• Documentation is written.

Design and add explanatory diagrams to README

• Design a architecture overview diagram
• Design project icon

Implement the customisation options and the final designs

User Story

As a 3rd party developer I need to be able to customise the appearance of payment methods screens.

Implementation Overview

• Implement the customisation agreement.
• Implement the final designs.

Acceptance Criteria

• The final designs are implemented.
• The customisation agreement is implemented.
• Tests are written and pass successfully.
• Documentation is written.

Designs links

Write project README

• Describe project purpose
• Provide integration instructions
• Provide quick steps on how to use the SDK
• Provide a overview of project architecture
• Provide build instructions
• Describe contribution process
• Provide licence

Design/Architect UI module

User story:

As a SDK developer I want to make my SDK usage same for whichever PSP the 3rd party developer uses. Since different PSP require different data for certain payment methods, 3rd party developers have to make small adjustments to support these PSP, increasing development cost, and decreasing ease of switching between the PSPs.

To resolve this issue we need to provide a UI module for each PSP. This UI module would be used instead of calling a specific registerPaymentMethod(params...) method. 3rd party developer would just call showPaymentMethodRegistrationUi() method and then the UI would take correct PSP specific data directly from the end-customer.

Implementation overview

To achieve this we need to work across platforms and agree on approach acceptable to each platform, while considering platform differences. Once we agree on the flows appearance and usage, we can proceed with stories for UI design, implementation and others.

Acceptance criteria:

• Agreement on how the UI modules will work across different PSPs is achieved

Update backend API implementation

User story:

As a Mobile SDK developer I need to update the backend API implementation so that I can correctly exchange the PSP alias for JWT alias.

Implementation overview

• Implement the new alias endpoint usage, implement the exchange alias endpoint usage.
• Provide proper handling interface.

Acceptance criteria:

• Implementation is updated
• All tests work fine
• Documentation is updated to reflect how to implement integration

Improve and refactor the sample app.

Implement the basic UI screens

User Story

As a customer I want to be able to choose the type of payment method that I want to register.

Implementation Overview

• Implement the basic UI that shows the list of payment methods that can be selected (Credit Card, SEPA and PayPal).

Acceptance Criteria

• The customer can see the 3 payment methods.
• Tests are written and pass successfully.
• Documentation is written.

Implement the UI component base mechanism

User Story

As a SDK developer I need a way to inform the core library about the proper payment methods for different PSPs.

Implementation Overview

• Implement the agreed mechanism (link for the mechanism documentation)

Acceptance Criteria

• Tests are written and pass successfully.
• Documentation is written.

Clean up project history

Implementation Overview

• Remove git history as it might contain confidential data
• Make sure there are no keys/confidential data in current code

Acceptance criteria:

• No git history
• No confidential data/keys etc. in the codebase

Migrate build script to Kotlin DSL.

Implement the BS PayOne UI module

User story:

As a SDK developer I want to offer prepared UI for BSP so that merchants using BSP can use our SDK easily.

Implementation overview

• Implement the credit card registration UI.
• Implement the SEPA registration UI.
• Implement the support for PayPal UI flow.

Acceptance criteria:

• UIs are implemented and working correctly.
• Tests are written and run successfully.
• Documentation is written.

Implement the basic payment method entry UI

User Story

As a customer I want to be able to enter my payment method information.

Implementation Overview

• Implement the basic UI that shows the list of correct entry fields and the validation of the fields.

Acceptance Criteria

• The customer sees the correct entry fields for each payment method.
• Tests are written and pass successfully.
• Documentation is written.

Centralize flow control into PSP coordinator

As a developer I would like to keep the PSP coordinator a central point of flow control for communication between client, SDK backend and PSPs, while keeping PSP easy to read and understand

To do this, PSP handlers must not have access to backend api, and flow logic should be moved to PSP coordinator. Furthermore to make the class readable and easy to modularize we need to encapsulate flow in a PSP specific classes.

Acceptance criteria:

• Coordinator, handler and flow classes are easy to understand and adding new PSPs is relatively easy

SDK usage documentation

User story:

As a 3rd party developer I would like to have excellent documentation and tutorials so I can quickly and easily start using the SDK in my projects.

Implementation overview

We already have a list of examples on how to use the SDK in the repository README, we need to add introduction, explanation of what each methods does in text and a diagram showing the effects of using each method. The detailed documentation found in the Android repository wiki is ment for developers of the SDK not 3rd party developers and is not affected y this story.

Acceptance criteria:

• README is updated, diagrams added, and it all looks really nice :)