# Debit Card

## Overview

This test plan outlines the comprehensive testing strategy for the Tokeo x Mastercard debit card integration, powered by Mercuryo. It covers unit, integration, and end-to-end testing to validate functionality, security, and user experience.

The plan ensures the system is robust for EU/UK users, focusing on card creation, funding with ADA, wallet integration, spending, security, and exception handling.

Testing was conducted in a staging environment simulating real-world conditions, including Cardano blockchain interactions and Mercuryo APIs.

Tools used: Postman for API testing, Selenium for UI automation, and custom scripts for blockchain simulations.

**Scope**

* In Scope: Core debit card features, error handling, security checks.
* Out of Scope: Live production traffic analysis (post-launch), third-party (Mastercard/Mercuryo) internal systems.

**Test Levels**

1. Unit Testing: Individual components (e.g., ADA conversion functions).
2. Integration Testing: Interactions between Tokeo app, Mercuryo APIs, and Cardano wallet.
3. End-to-End Testing: Full user journeys from onboarding to payment.

**Test Environment**

* Tokeo App: Version 1.2 (iOS/Android simulators).
* Blockchain: Cardano Testnet.
* Devices: iPhone 14 emulator, Pixel 6 emulator.
* Network: Simulated low-latency and high-latency conditions.

**Test Scenarios and Cases**

1\. Ability to Create a Virtual Debit Card via Tokeo / Mercuryo

·   Objective: Verify seamless card issuance.

·   Preconditions: User logged in, eligible region (EU/UK).

**·   Test Cases:**

o   TC1.1: Successful creation with new KYC – Expected: Card generated in <2 min.

o   TC1.2: Creation for existing Mercuryo KYC'd user – Expected: Instant issuance.

o   TC1.3: Invalid region – Expected: Geo-block error.

·   Coverage: 15 unit tests (API payloads), 10 integration tests (Mercuryo callbacks).

&#x20;

2\. Ability to Fund / Deposit a Card with ADA

·   Objective: Ensure ADA-to-fiat conversion and deposit.

·   Preconditions: Active card, sufficient ADA balance.

·   Test Cases:

o   TC2.1: Deposit 100 ADA – Expected: Balance updated, transaction confirmed.

o   TC2.2: Partial staking rewards deposit – Expected: Successful with rewards wallet.

o   TC2.3: Low balance – Expected: Error prompt to add funds.

·   Coverage: 20 unit tests (conversion math), 15 integration tests (blockchain tx).

&#x20;

3\. Ability to View Card in Apple or Google Wallet

·   Objective: Confirm digital wallet integration.

·   Preconditions: Card created and funded.

·   Test Cases:

o   TC3.1: Add to Apple Pay – Expected: Tokenized card appears in Wallet app.

o   TC3.2: Add to Google Pay – Expected: Successful on Android.

o   TC3.3: Device incompatibility – Expected: Graceful fallback message.

·   Coverage: 10 integration tests (wallet APIs), device-specific runs.

&#x20;

4\. Ability to Use the Card (Spend) Where Mastercard is Accepted

·   Objective: Validate transactions.

·   Preconditions: Funded card in digital wallet.

·   Test Cases:

o   TC4.1: Online purchase simulation – Expected: Approval, balance deduction.

o   TC4.2: In-app tracking – Expected: Real-time update in Tokeo.

o   TC4.3: Declined transaction (over limit) – Expected: Error with reason.

·   Coverage: 12 end-to-end tests (mock merchants), 8 integration tests (Mastercard gateway).

&#x20;

5\. Internal Security Quality Review

·   Objective: Identify vulnerabilities.

·   Approach: Static analysis (SonarQube), penetration testing (OWASP ZAP), compliance scans (GDPR/PCI-DSS).

·   Test Cases:

o   TC5.1: API endpoint security – Expected: No SQL injection/XSS.

o   TC5.2: Data encryption – Expected: All sensitive data encrypted in transit/rest.

o   TC5.3: Auth checks – Expected: MFA enforced for card actions.

·   Coverage: Full codebase scan; report internal.

&#x20;

6\. Exception Scenarios Adequately Handled

·   Objective: Ensure user-friendly error management.

·   Preconditions: Various failure states simulated.

·   Test Cases:

o   TC6.1: Insufficient Funds – Expected: Message: "Insufficient ADA balance. Please add more funds or try a smaller amount." Redirect to top-up.

o   TC6.2: KYC Failure – Expected: Message: "KYC verification required. Complete it now or contact support." Link to portal/chat.

o   TC6.3: Network Issues – Expected: "Transaction failed due to network congestion. Retry in 30 seconds?" Auto-retry.

o   TC6.4: Invalid Inputs – Expected: "Invalid amount: Must be between €10 and €5000." Real-time validation.

o   TC6.5: General Errors – Expected: "Contact Support" button with pre-filled details; escalation to ticket system.

·   Coverage: 50+ scenarios in staging; user feedback simulation for messaging.

**Execution and Results**

* Total Tests: 150+ across levels.
* Pass Rate: 98% (minor issues fixed, e.g., UI tweaks).
* Defects: 5 low-severity (resolved); no critical.
* Tools: JIRA for tracking, Allure for reports.

**Risks and Mitigations**

* Risk: Blockchain volatility – Mitigation: Fallback to testnet.
* Risk: API rate limits – Mitigation: Throttling in tests.

This plan ensures the debit card is secure and ready for marketing and launch.<br>


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://tokeo.gitbook.io/tokeo/tokeo/technical-information/debit-card.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
