Description

The Hyperswitch SDK is the frontend part of the payment experience, handling how users interact with the payment process on mobile apps. When a user opens the payment sheet, they typically see a "Pay Now" button to complete the transaction. To make this experience more modern and engaging, the plan is to replace that traditional "Pay Now" button with a Swipe to Pay action. This will allow users to swipe across the screen to confirm their payment, making the process feel smoother and more interactive. However, it’s important to maintain backward compatibility, so older versions or users who prefer the standard button will still have the option to use it.

Getting started

1. Get familiar with ReScript.
2. Check the README.md for project structure and setup instructions.
3. To setup locally, follow these steps

#  Clone repository
cd hyperswitch-client-core
git submodule update --init --recursive
yarn install
yarn run server     # This starts the mock server
yarn run re:start   # In another terminal

Current Behavior:

• The Pay Now button is used to initiate the payment process.
• On clicking the button, a progress bar is shown, and the payment confirmation flow proceeds as usual.

Expected Behavior:

• The Pay Now button should be replaced by a Swipe to Pay feature.
• The user should swipe to confirm the payment instead of clicking a button.
• The existing payment flow must not be affected by this change.

Details:

1. Swipe to Pay Design

The UI needs to transition from a simple button press to a swipe action without impacting the overall layout and user experience.

• Action: Design the Swipe to Pay feature such that it visually communicates the action to the user, making it intuitive.
• Task: Create mockups or design assets for the swipe interaction (e.g., a draggable bar with labels like "Swipe to Pay").
• Task: Ensure the swipe area is visually distinct but blends in with the SDK’s theme. Swipe Interaction Implementation:

2. Swipe Interaction Implementation

Develop the logic to handle swipe gestures, replacing the button click.

• Task: Ensure that the swipe gesture detects partial swipes and completes only on a full swipe.
• Task: Add haptic feedback or a small animation to enhance the user experience upon completing the swipe.

3. Maintaining the Existing Payment Flow

The current payment process, which starts with a Pay Now button, shows a progress bar, and confirms payment, should remain unchanged beyond the interaction trigger.

• Action: Refactor the code so that the swipe interaction triggers the same payment flow as the button click.
• Task: Map the swipe gesture to the existing Pay Now functionality, ensuring no disruptions in the backend logic or payment process.

4. Progress Bar Handling

The progress bar currently appears after clicking the Pay Now button. This should still occur after the swipe action.

• Action: Display the progress bar as soon as the user completes the swipe.
• Task: Implement a smooth transition from the swipe action to showing the progress bar, ensuring it reflects the same loading states as before.

5. State Management and Error Handling

Handle payment errors or failed attempts while using the swipe functionality.

• Action: Make sure that if the swipe action is interrupted or payment fails, the app can reset back to the default state, allowing users to try again.
• Task: Implement error states and messages that reset the swipe feature if a payment error occurs.
• Task: Ensure that partial swipes or errors during the swipe do not interfere with the backend payment flow.

6. Security and Swipe Confirmation

Swipe actions could introduce security concerns if not carefully implemented, such as accidental swipes or false triggers.

• Action: Add extra measures like requiring a full and deliberate swipe to confirm the payment, avoiding accidental triggers.
• Task: Add additional checks such as re-confirmation of payment details upon swipe completion for extra security.

7. Backward Compatibility

Some users may prefer the Pay Now button or expect it based on older versions of the SDK.

• Task: Maintain backward compatibility with configurations or flags that allow the merchant to choose between the button or swipe interface.

8. Testing & Quality Assurance

Extensive testing is required to ensure that the swipe interaction works seamlessly across various devices and does not affect the underlying payment functionality.

• Action: Test the swipe feature across multiple screen sizes and OS versions to ensure consistency.
• Task: Test payment flows with both Swipe to Pay and Pay Now options to ensure no impact on functionality.

Contribution Guidelines:

• Fork the repository and create a new branch for your work.
• Write clean, well-documented code with clear commit messages.
• Make sure to follow our coding standards and contribution guidelines.

If you have any questions or need help getting started, feel free to ask in the comments!