System Requirements Document

1. Introduction

This System Requirements Document (SRD) defines the requirements for a focused POS payment proof of concept (POC) to be delivered by fxis.ai. The POC determines whether a single selected terminal can support the exact requested "201.3" / six-digit offline payment process through an approved provider interface, and whether eligible payments can settle into the nominated Indian Overseas Bank (IOB) business account.

This is an experimental POC deliverable, not a production system. Its output is evidence and a proceed, conditional or stop recommendation. A working demonstration alone is not proof of bank settlement. Unsupported capabilities and pending approvals must be explicitly recorded.

The POC will resolve four questions:

• Can the selected terminal be accessed, provisioned and used for a new application?
• Does the provider support the exact transaction operation, the six-digit value, and the intended remote card-entry method?
• Can the application obtain reliable results and recover uncertain outcomes without duplicate submission?
• Can an approved pilot transaction be reconciled with a credit to the IOB account?

2. System Overview

The POC is a new minimal Android terminal application built with Kotlin and Android Studio, working against the installed certified payment app or SDK on a target terminal. Prior source code is not required. Offline functionality is acknowledged as already installed; the POC establishes what that mode does, whether the new application can invoke it, and how its transactions reach the provider and settle.

Proposed boundary: One merchant, one selected terminal, one provider and one agreed transaction flow. PAX A920Pro is the provisional target; another existing terminal may be considered if the target is unsuitable, subject to agreement on any effort change. Execution uses small approved amounts and one enabled currency; eligibility for the requested EUR, USD and GBP is assessed separately.

Expected evidence and outcome: device inventory, provider validation, test integration demonstration with QA evidence, a controlled live pilot reconciliation (where approved) or documented pending status, and a findings/handover package.

Schedule: 14–21 working days of active execution, approximately 3–5 working weeks with the proposed team and prerequisites ready. External waiting time is additional and cannot yet be bounded. The first 2–3 working days form an assessment checkpoint; dependent development proceeds only once a supported route is established.

3. Functional Requirements

Requirements are written as user stories grouped by POC area. Each named capability from the source material is preserved as a distinct story.

3.1 POC Questions and Boundary

• FR-1 — As a POC reviewer, I want the POC to determine whether the selected terminal can be accessed, provisioned and used for a new application, so that terminal feasibility is evidenced.
• FR-2 — As a POC reviewer, I want the POC to determine whether the provider supports the exact transaction operation, the six-digit value and the intended remote card-entry method, so that requirement eligibility is confirmed.
• FR-3 — As a POC reviewer, I want the POC to determine whether the application can obtain reliable results and recover uncertain outcomes without duplicate submission, so that reliability is evidenced.
• FR-4 — As a POC reviewer, I want the POC to determine whether an approved pilot transaction can be reconciled with a credit to the IOB account, so that settlement is evidenced.
• FR-5 — As a POC sponsor, I want the POC scope limited to one merchant, one selected terminal, one provider and one agreed transaction flow, so that scope is controlled.
• FR-6 — As a POC sponsor, I want PAX A920Pro set as the provisional target terminal, so that execution has a defined default.
• FR-7 — As a POC sponsor, I want another existing terminal considered if the provisional target is unsuitable, subject to agreement on any effort change, so that an alternative route is possible.
• FR-8 — As a POC sponsor, I want execution to use small approved amounts and one enabled currency, so that financial risk is controlled.
• FR-9 — As a POC sponsor, I want EUR, USD and GBP eligibility assessed separately, so that multi-currency support is scoped without assuming it.
• FR-10 — As a POC reviewer, I want the POC to deliver evidence and a proceed, conditional or stop recommendation, so that the next step is clear.
• FR-11 — As a POC reviewer, I want unsupported capabilities and pending approvals explicitly recorded, so that the outcome is not overstated.

3.2 Device Inspection and Assessment (Gate 1)

• FR-12 — As a POC implementation lead, I want to inspect the supplied device without altering its payment configuration, so that the existing payment setup stays intact.
• FR-13 — As a POC implementation lead, I want to inventory the terminal's model, OS and firmware, so that the device baseline is documented.
• FR-14 — As a POC implementation lead, I want to identify the installed payment app/provider, so that the correct integration target is known.
• FR-15 — As a POC implementation lead, I want to record terminal connectivity, printer capability, marketplace and installation restrictions, so that constraints are documented.
• FR-16 — As a POC implementation lead, I want to identify the technical owner of the installed application, so that the provider point of contact is established.
• FR-17 — As a POC implementation lead, I want to obtain documentation defining the requested operation and its supported integration interface, so that a documented API contract — not a menu label or six-digit input field — governs implementation.
• FR-18 — As a POC implementation lead, I want to issue the device inventory and checkpoint report within 2–3 working days of active assessment, so that the proceed/pause/stop decision can be taken.
• FR-19 — As a POC implementation lead, I want dependent work to proceed only when a compatible route and the exact transaction capability are confirmed, so that speculative implementation is avoided.
• FR-20 — As a POC implementation lead, I want to pause dependent work and list missing evidence when essential access or information is pending, so that progress is not fabricated.
• FR-21 — As a POC implementation lead, I want to deliver a stop recommendation rather than continue speculative implementation when the requirement is unsupported, so that effort is not wasted.

3.3 Provider Validation

• FR-22 — As a POC implementation lead, I want to validate the exact transaction operation and its code meaning against the provider, so that the flow's semantics are known.
• FR-23 — As a POC implementation lead, I want to validate remote-entry eligibility, offline behavior, limits and currencies, so that the business flow's supported boundaries are known.
• FR-24 — As a POC implementation lead, I want to validate the account settlement route, so that settlement feasibility is established.

3.4 SDK and Test Setup

• FR-25 — As an Android developer, I want one compatible interface selected, so that a single integration route is pursued.
• FR-26 — As an Android developer, I want the POC application registered and provider test credentials obtained, so that integration tests can run.
• FR-27 — As an Android developer, I want one terminal configured, so that the target environment is ready.
• FR-28 — As an Android developer, I want to verify that our application can invoke the provider flow, so that invocation is demonstrated.
• FR-29 — As an Android developer, I want provider-approved test cards or scenarios, so that payment acceptance — not a mock — is proven; mocks may support screen development but cannot satisfy payment acceptance.

3.5 Target Transaction Sequence and Minimal Application

• FR-30 — As a terminal operator, I want the application to check terminal, provider app and environment readiness, so that the environment is confirmed before payment.
• FR-31 — As a terminal operator, I want unresolved prior transactions surfaced before a new payment, so that open outcomes are not ignored.
• FR-32 — As a terminal operator, I want to enter the permitted amount, enabled currency and business reference, so that a payment can be initiated.
• FR-33 — As a terminal operator, I want inputs validated and a unique application request ID created, so that each request is traceable.
• FR-34 — As a terminal operator, I want to invoke the provider secure interface for the permitted card entry and the six-digit value at its documented stage, so that secure card entry stays within the supported flow.
• FR-35 — As a terminal operator, I want the application to submit once and record a verified provider result and reference, so that results are accurate.
• FR-36 — As a terminal operator, I want the outcome marked unknown when a reliable response is unavailable, so that uncertain results are not fabricated.
• FR-37 — As a terminal operator, I want to print a masked receipt for the established result, so that a payment record is provided.
• FR-38 — As a terminal operator, I want printer failure not to trigger another payment, so that no duplicate charge occurs.
• FR-39 — As a terminal operator, I want a result view, so that the transaction outcome is visible.
• FR-40 — As a terminal operator, I want basic local transaction records, so that prior transactions are retained locally.

• FR-41 — As a terminal operator, I want a minimal transaction view, so that I can review transactions; advanced search and reporting are excluded.
• FR-42 — As a POC implementation lead, I want the approved live pilot transaction mapped through settlement records to the actual IOB credit, so that settlement is traced end to end.

3.6 Reliability, Duplicate Control and Recovery

• FR-43 — As an Android developer, I want repeated submission prevented during an active request, so that duplicate charges are avoided.
• FR-44 — As an Android developer, I want provider idempotency used where available and unique application references retained, so that retries are safe.
• FR-45 — As a terminal operator, I want documented statuses mapped to approved, declined, cancelled, pending or unknown, so that outcomes are classified correctly.
• FR-46 — As a terminal operator, I want unrecognized responses to remain unresolved, so that no fabricated approval occurs.
• FR-47 — As a terminal operator, I want the original request queried after a timeout or restart before permitting a replacement, so that uncertain outcomes are resolved first.
• FR-48 — As a terminal operator, I want provider-assisted resolution required where lookup is unavailable, with the limitation recorded, so that uncertainty is handled explicitly.
• FR-49 — As an Android developer, I want cancellation/reversal tested through supported methods only, so that unsupported reversal paths are not emulated.
• FR-50 — As a terminal operator, I want a receipt reprint to not initiate another transaction, so that reprints cannot cause duplicate charges.
• FR-51 — As an Android developer, I want duplicate-tap control demonstrated, so that no second active request is created from repeated taps.
• FR-52 — As a POC implementation lead, I want restart recovery to reuse the original reference, so that recovery does not create new requests.

3.7 Offline Scenarios

• FR-53 — As a POC implementation lead, I want to test the permitted operation while connected when offline means connected manual completion, so that this interpretation is validated.
• FR-54 — As a POC implementation lead, I want to test only the provider-managed capability and later submission rules when offline means acceptance without connectivity, so that offline behavior is bounded to supported capability.
• FR-55 — As a POC implementation lead, I want a clear failure or pending outcome verified and the restriction documented when disconnected acceptance is unsupported, so that unsupported acceptance is not emulated.
• FR-56 — As a POC implementation lead, I want raw card data never queued, so that offline handling does not capture sensitive data.
• FR-57 — As a POC implementation lead, I want supported disconnection/reconnection behavior tested, so that interruption handling is evidenced.

3.8 Receipt Validation

• FR-58 — As a terminal operator, I want one basic masked receipt generated through the permitted interface, so that receipt output is validated.
• FR-59 — As a terminal operator, I want a reprint test through the permitted interface (subject to SDK access), so that reprint capability is validated.

3.9 Settlement Verification (Gate 3)

• FR-60 — As a POC implementation lead, I want the nominated account registered through the provider, so that settlement is directed to the designated IOB business account.
• FR-61 — As a POC implementation lead, I want provider and merchant authorization arranged for a controlled live pilot, so that no live transaction is executed without those authorizations.
• FR-62 — As a POC implementation lead, I want the amount, currency, participants and settlement account agreed before the pilot, so that pilot parameters are fixed.
• FR-63 — As a POC implementation lead, I want to execute the authorized pilot and obtain the provider settlement record, so that settlement evidence is captured.
• FR-64 — As a POC implementation lead, I want to observe the applicable settlement cycle, so that the settlement timeline is understood.
• FR-65 — As a POC implementation lead, I want to compare transaction and settlement records with the actual IOB credit, so that settlement is confirmed.
• FR-66 — As a POC implementation lead, I want gross amount, fees/deductions, net credit, currency and settlement reference compared, so that deductions and net value are understood.
• FR-67 — As a POC implementation lead, I want an aggregate payout accepted only with a traceable mapping to the pilot transaction, so that reconciliation remains verifiable.
• FR-68 — As a POC implementation lead, I want the settlement outcome recorded, so that evidence is complete.

3.10 Backend Boundary

• FR-69 — As an Android developer, I want the baseline to have the terminal app invoke the supported payment app/SDK without a new backend, so that the minimal architecture holds.
• FR-70 — As a POC implementation lead, I want a minimal secure test service (with hosting and revised effort) agreed at Gate 1 if server-held secrets or cloud callbacks are mandatory, so that the requirement is met within a controlled boundary; a production backend or portal is excluded.

3.11 Provider Route and References

• FR-71 — As a POC implementation lead, I want the installed provider investigated first, so that the most likely supported route is prioritised.
• FR-72 — As a POC implementation lead, I want at most one mutually agreed alternative provider route evaluated, so that broad provider sourcing is avoided.
• FR-73 — As a POC implementation lead, I want the documented integration routes (PAX Android and POSLink; Pine Labs POS integration and application approval; Razorpay POS gateway SDK examples; IOB POS service) treated as possible routes rather than confirmed support, so that unsupported assumptions are not made.

3.12 Security and Deployment

• FR-74 — As a POC implementation lead, I want PAN, CVV, PIN, OTP and sensitive authentication data kept out of the database, logs, screenshots and exports, so that sensitive data is protected.
• FR-75 — As a POC implementation lead, I want the six-digit value handled according to its confirmed classification and provider rules, so that its handling is compliant.
• FR-76 — As an Android developer, I want Android Keystore or approved storage used for permitted local credentials, so that local secrets are protected.
• FR-77 — As an Android developer, I want secrets excluded from source, so that credentials are not leaked.
• FR-78 — As a POC implementation lead, I want sanitized references, result codes, timestamps and app/SDK versions collected, so that evidence is reproducible and safe.
• FR-79 — As a POC implementation lead, I want card/account information redacted in evidence, so that shared artifacts contain no sensitive data.
• FR-80 — As a POC implementation lead, I want a development terminal or signed APK arranged as needed, so that the POC can run on the target.
• FR-81 — As a POC implementation lead, I want the terminal not rooted, its controls not bypassed and payment keys not altered, so that device integrity and provider trust are preserved.

3.13 Local Storage and State Integrity

• FR-82 — As an Android developer, I want Room or equivalent local storage for non-sensitive records (application/provider references, amount, currency, timestamps, payment state), so that transactions are recorded without sensitive data.
• FR-83 — As a terminal operator, I want settlement evidence tracked separately, so that settlement state is distinct from payment state.
• FR-84 — As a terminal operator, I want provider approval, local acceptance and actual bank settlement tracked as distinct states, so that they are never conflated.

3.14 QA, Findings and Handover

• FR-85 — As a QA engineer, I want an executed test matrix with corrections and a repeatable demonstration, so that results are reproducible.
• FR-86 — As a POC reviewer, I want the POC to consolidate verified capabilities, evidence, constraints and unresolved items, so that findings are complete.
• FR-87 — As a POC reviewer, I want full development estimated using the proven interface, so that next-scope sizing is grounded.
• FR-88 — As a POC reviewer, I want integration reported as demonstrated and settlement as unverified when live access or settlement remains pending, so that the full flow is not declared proven.
• FR-89 — As a POC reviewer, I want the POC source, dependency/version inventory, build notes, permitted test APK, demonstration, sanitized test results and findings delivered, so that the client can review and reproduce.
• FR-90 — As a POC reviewer, I want evidence to identify hardware, firmware, payment app and SDK versions, so that results can be reproduced.
• FR-91 — As a POC reviewer, I want outcome classified as proceed, conditional or stop against defined criteria, so that the recommendation is objective.
• FR-92 — As a POC reviewer, I want untested limits, currencies and entry modes recorded as unverified, so that the outcome scope is explicit.
• FR-93 — As a POC reviewer, I want critical payment-result or duplicate-charge defects to prevent a proceed recommendation, so that safety gates the outcome.
• FR-94 — As a POC reviewer, I want completed assessment and blocker evidence delivered if the POC is stopped early, without describing integration as completed, so that partial outcomes are represented honestly.
• FR-95 — As a POC reviewer, I want a client review step confirming the recorded outcome and next step, so that handover is agreed.

3.15 Client Arrangements and Start Checklist

• FR-96 — As a client business representative, I want to arrange one terminal in India with authorized access, or an initial remote inspection followed by physical access if needed, so that assessment can begin.
• FR-97 — As a client business representative, I want to provide the supplier or installed-provider contact if available, so that the provider can be investigated.
• FR-98 — As a client business representative, I want to provide a PPR/login ID only if its issuing platform and authorization can be established, so that unnecessary credentials are avoided.
• FR-99 — As a client business representative, I want to nominate an authorized business representative for merchant onboarding and IOB settlement and a POC reviewer, so that approvals are in place.
• FR-100 — As a client business representative, I want to confirm typical and maximum transaction amounts and expected volume for provider eligibility checks, so that limits can be validated.
• FR-101 — As a client business representative, I want EUR, USD and GBP recorded as requested currencies, so that currency eligibility is tracked.
• FR-102 — As a client business representative, I want provider credentials and bank documents submitted through the provider's approved onboarding channel, with no internet-banking passwords required, so that onboarding is secure.
• FR-103 — As a POC implementation lead, I want to obtain the installed-app details, protocol definition, code classification, SDK access, permitted card entry, transaction lifecycle, offline rules, signing process and settlement evidence, so that provider-owned questions are answered by the team.

3.16 Dependencies, Blockers and Governance

• FR-104 — As a POC implementation lead, I want dependent development stopped and the exact restriction documented when no provider-owned 201.3 specification exists or the six-digit operation is unsupported, so that unsupported work is not attempted.
• FR-105 — As a POC implementation lead, I want an authorized development device requested when the UK-sourced device is locked to another marketplace/acquirer or is unsuitable for Indian provisioning, with replacement scope agreed separately, so that the correct device is used.
• FR-106 — As a POC implementation lead, I want the restriction reported when remote card entry, requested values or currencies are not permitted, so that a standard card-present payment is not mistaken for the requested method.
• FR-107 — As a POC implementation lead, I want actual offline-mode behavior recorded when the SDK path is unavailable or later submission fails, so that requirement fit is assessed against real behavior.
• FR-108 — As a POC implementation lead, I want documented provider-assisted evidence used where possible when status lookup, printer access or settlement data is unavailable, so that validation continues to the extent supported.
• FR-109 — As a POC implementation lead, I want to pause, report completed work, and propose revised effort before proceeding when approvals or compatibility fixes exceed the allowance, so that scope changes are controlled.
• FR-110 — As a POC sponsor, I want fxis.ai to own integration design, implementation, tests, coordination and reporting, so that delivery responsibility is clear.
• FR-111 — As a POC sponsor, I want the client to own authorized access, merchant participation and account/pilot approvals, so that prerequisite responsibility is clear.

• FR-112 — As a POC sponsor, I want the provider to own permitted payment capabilities, provisioning, credentials, processing and settlement, so that provider responsibility is clear.
• FR-113 — As a POC sponsor, I want acknowledged that custom application code cannot remove provider restrictions, so that expectations match the provider's authority.
• FR-114 — As a POC implementation lead, I want each external wait recorded with its owner and expected response date, and reforecast at checkpoints, so that schedule uncertainty is visible.
• FR-115 — As a POC implementation lead, I want provider-dependent changes to require a revised estimate before extra work, so that unplanned effort is not absorbed.

3.17 Acceptance Deliverables

• FR-116 — As a POC reviewer, I want the amount, enabled currency, provider-approved scenarios and named reviewers agreed before execution, so that acceptance is defined.
• FR-117 — As a POC reviewer, I want delivery of the demonstration, test matrix, sanitized evidence, POC source/build notes, gaps and full-development recommendation, so that the POC concludes with a complete package.

4. User Personas

• Client Business Representative — The merchant owner or authorized delegate. Arranges one terminal in India with authorized access, provides the supplier/installed-provider contact, nominates the merchant onboarding and IOB settlement representative, and confirms typical/maximum transaction amounts, expected volume and the requested EUR/USD/GBP currencies. Does not explain protocol internals.
• POC Reviewer — The nominated client-side reviewer (with fxis.ai). Confirms the recorded outcome and next step, reviews sanitized evidence and the test matrix, and confirms the proceed/conditional/stop classification. Uses the evidence artifacts, not the terminal itself.
• POC Implementation Lead / Shared Technical Lead — Owns provider coordination, integration design, device inspection, provider validation, Gate reporting, and effort/schedule reforecast. Runs the assessment and drives gate decisions.
• Android Developer — Implements the Kotlin/Android application and provider adapter, configures the terminal, executes integration and recovery tests through supported methods only, and runs the POC on the target device.
• QA / Evidence Reviewer — Executes the test matrix, verifies rejection/duplicate/timeout/restart/receipt/security scenarios, and collects sanitized, reproducible evidence.

External / system actors (not personas): the payment Provider (owns permitted capabilities, provisioning, credentials, processing and settlement), the installed certified payment app/SDK, the IOB settlement account, and the terminal hardware/marketplace.

5. Core User Flows

5.1 Assessment and Gate 1 Flow

1. Client arranges authorized terminal access (or remote inspection followed by physical access) and provides the installed-provider/supplier contact.
2. Implementation lead inspects the device without altering its payment configuration and records model, OS, firmware, installed app/provider, connectivity, printer, marketplace and installation restrictions.
3. Implementation lead obtains documentation defining the requested operation and its supported integration interface.
4. Within 2–3 working days, the device inventory and checkpoint report are issued.
5. Decision: proceed (compatible route and exact transaction capability confirmed), pause (missing evidence listed), or stop (requirement unsupported).

5.2 Test Transaction Flow (Gate 2)

1. Register the POC application; obtain provider test credentials; configure one terminal.
2. Operator checks terminal, provider app and environment readiness; unresolved prior transactions are surfaced.
3. Operator enters the permitted amount, enabled currency and business reference; inputs are validated and a unique application request ID is created.
4. Application invokes the provider secure interface for the permitted card entry and the six-digit value at its documented stage.
5. Application submits once and records a verified provider result and reference, or marks the outcome unknown.
6. Operator prints a masked receipt for the established result; printer failure does not trigger another payment.
7. Success, rejection and recovery scenarios are tested using provider-approved test cards/scenarios.

5.3 Duplicate / Timeout / Restart Recovery Flow

1. During an active request, repeated taps are suppressed.
2. After a timeout or restart, the original request is queried before any replacement is permitted.
3. If lookup is unavailable, provider-assisted resolution is required and the limitation is recorded.
4. Statuses are mapped to approved, declined, cancelled, pending or unknown; unrecognized responses remain unresolved.
5. Cancellation/reversal is tested only through supported methods; a receipt reprint never initiates another transaction.

5.4 Offline Scenario Flow

1. Determine the meaning of "offline" for the installed mode (connected manual completion vs acceptance without connectivity).
2. If connected manual completion — test the permitted operation while connected.
3. If acceptance without connectivity — test only the provider-managed capability and later submission rules.
4. If disconnected acceptance is unsupported — verify a clear failure or pending outcome and document the restriction.
5. Raw card data is never queued; unsupported acceptance is never emulated.

5.5 Settlement Verification Flow (Gate 3)

1. Register the nominated account through the provider.
2. Arrange provider and merchant authorization for a controlled live pilot; agree amount, currency, participants and settlement account.
3. Execute the authorized pilot and obtain the provider settlement record.
4. Observe the applicable settlement cycle.
5. Compare gross amount, fees/deductions, net credit, currency and settlement reference; match the actual IOB credit (an aggregate payout requires traceable mapping).
6. Record the outcome; report settlement as unverified if it remains pending.

5.6 Findings and Handover Flow (Gate 4)

1. Consolidate verified capabilities, evidence, constraints and unresolved items.
2. Estimate full development using the proven interface.
3. Classify the outcome: proceed, conditional or stop.
4. Deliver POC source, dependency/version inventory, build notes, permitted test APK, demonstration, sanitized test results and findings.
5. Client review confirms the recorded outcome and next step.

6. Visuals, Colors and Theme

Not specified by the source; the following restrained defaults are derived for a payment-terminal utility / evidence-driven POC:

• Overall tone: utilitarian, high-contrast, minimal. The application exists to prove transaction behavior, not to present a brand.
• Palette: neutral graphite/slate surfaces with a single restrained accent for primary actions. A distinct, conventionally understood status color set is used only for transaction states — approved, declined, cancelled, pending, unknown — so states are never visually conflated.
• Typography: a single legible sans-serif with clear numerals for amounts, currency and references; amounts and results are the visual focus.
• Result emphasis: the transaction result and its state (provider approval vs local acceptance vs bank settlement) are visually separated.
• Evidence suitability: sanitized screens used in evidence must never show PAN, CVV, PIN, OTP or other sensitive data.

7. Signature Design Concept

"Distinct states, single source of truth." The signature concept is a state ladder that visually separates three things that are easily conflated in payment flows: provider approval, local acceptance, and actual bank settlement. Each state is shown as its own clearly labelled step, with unknown/unresolved outcomes held as first-class visible states rather than being hidden. Duplicate-risk is designed out at the interaction level: a single active request is evident, and a reprint or printer failure can never read as a new payment.

8. Interaction Model & Motion Direction

• Deliberate confirmation model: no optimistic success. A result is only shown as established when a verified provider result is recorded; otherwise it is shown as unknown.
• Single-submission discipline: while a request is active, re-submission controls are disabled and repeated taps are absorbed.
• Recovery-first: on timeout or restart, the interface directs the operator to check the original request rather than start a new one.
• Motion: minimal and functional only — brief state transitions used to signal request-in-progress, result-established and needs-recovery. No decorative animation.
• Receipt handling: receipt print and reprint are separate, non-charging actions.

9. Non-Functional Requirements

• Security / data protection: PAN, CVV, PIN, OTP and sensitive authentication data must not enter the database, logs, screenshots or exports; the six-digit value is handled per its confirmed classification and provider rules; local credentials use Android Keystore or approved storage; secrets are excluded from source; card/account data is redacted in evidence.
• Device integrity: terminal must not be rooted, its controls must not be bypassed, and payment keys must not be altered.
• Reliability: repeated submission prevented during an active request; provider idempotency used where available; unique application references retained; unknown outcomes resolved before retry.
• State integrity: provider approval, local acceptance and actual bank settlement tracked and displayed as distinct states; unrecognized responses remain unresolved.
• Traceability / reproducibility: evidence identifies hardware, firmware, payment app and SDK versions; sanitized references, result codes, timestamps and app/SDK versions collected.
• Scope discipline: no live transaction without authorization; no emulation of unsupported acceptance; no queuing of raw card data; no receipt reprint causing another charge.
• Schedule: 14–21 active working days (≈3–5 working weeks) with prerequisites ready; the initial 2–3 days are included, not added; external waiting time is additional and reforecast at checkpoints.
• Acceptance: production readiness is not an acceptance criterion; critical payment-result or duplicate-charge defects prevent a proceed recommendation.

10. Tech Stack

• Platform / language: Kotlin, built in Android Studio.
• Target device / OS: PAX A920Pro (provisional); PayDroid/Android build; SDK levels selected against the actual installed build.
• Payment integration: the installed certified payment app or SDK, invoked through a small provider adapter encapsulating payment launch, result mapping, status lookup and supported cancellation. Secure card entry and processing stay within the provider's supported flow.
• Candidate provider routes (to be confirmed, not assumed): PAX Android and POSLink development access; Pine Labs POS integration and application approval; Razorpay POS gateway SDK examples.
• Local storage: Room or equivalent, for non-sensitive records only (application/provider references, amount, currency, timestamps, payment state); settlement evidence tracked separately.
• Secure local storage: Android Keystore or approved storage for permitted local credentials.
• Backend: none in the baseline — the terminal app invokes the supported payment app/SDK without a new backend. A minimal secure test service (with hosting and revised effort) is included only if server-held secrets or cloud callbacks are mandatory, agreed at Gate 1. A production backend or portal is excluded.
• Settlement: no direct IOB integration is assumed; settlement is via the provider's supported route and observed against the IOB account credit.

11. Assumptions and Constraints

Assumptions

• The selected terminal can be accessed, provisioned and used for a new application (to be confirmed at Gate 1).
• Offline functionality is already installed; the POC establishes what it does, whether the application can invoke it, and how its transactions reach the provider and settle.
• Prior source code is not required; the previous application's source is not needed.
• Previous source code apart, a PPR/login ID is useful only if its issuing platform and authorization can be established.
• Internet-banking passwords are not needed; credentials and bank documents go through the provider's approved onboarding channel.
• Provider representatives and the client participate at checkpoints.

Constraints / Exclusions

• Scope boundary: one merchant, one selected terminal, one provider, one agreed transaction flow; small approved amounts, one enabled currency; EUR/USD/GBP eligibility assessed separately.
• Excluded: production-ready retail POS, inventory, supplier payments, ecommerce, accounting integration, dashboards, user-management portal and multi-terminal rollout.
• Excluded: a new acquiring host, custom payment kernel, undocumented protocol implementation, direct bank debit interface or key-injection infrastructure.
• Excluded: full refunds, report exports, automated bank statement ingestion, production monitoring, availability commitments and ongoing support.
• Excluded: production-volume load tests, high-value live trials, and exhaustive international-card or three-currency certification.

• Excluded: guaranteed merchant approval, certification, signing or marketplace release; coordination for the pilot is included but full production release belongs to a later SOW.
• An alternative payment method will not be substituted without agreement and will not count as validation of the original requirement; the POC does not generate approval codes or treat any entered six-digit value as proof of authorization.
• Broad provider sourcing is excluded; at most one mutually agreed alternative route is evaluated.
• New providers, devices, backends or transaction types require written scope/effort agreement; full development and ongoing support require a separate SOW.
• Commercial: POC fees and payment milestones are agreed before commencement; SDK licensing, hardware, courier, hosting, onboarding and transaction fees are separate unless expressly included; a stop/pause delivers completed findings and billing follows the agreed completed milestone.
• Schedule conditions: assessment begins when authorized access is available and each task starts when prerequisites are met; the 3–5 week range reflects 14–21 weekdays, review coordination and partial QA availability, not a fixed end-date promise.
• Milestones: M1 assessment and proceed/pause/stop decision; M2 test integration demonstration and QA evidence; M3 pilot reconciliation or documented pending approval/settlement; M4 findings and handover. If stopped early, completed assessment and blocker evidence are delivered without describing integration as completed.
• Team: one Android developer for implementation; a shared technical lead for provider coordination and design; part-time QA for scenarios and evidence; a backend developer only if a separately agreed test service is necessary.

Dependencies and Blockers

Required Test Evidence

Schedule (active working days)

12. Glossary

• 201.3 — The exact requested transaction operation the POC must validate against the provider.
• Six-digit value — The requested value submitted as part of the "201.3 / six-digit offline" process; it is not proof of authorization and is handled per confirmed classification and provider rules.
• POC — Proof of concept; the experimental deliverable producing evidence and a proceed/conditional/stop recommendation.
• IOB — Indian Overseas Bank; the nominated business account for settlement.
• Provider — The external party owning permitted payment capabilities, provisioning, credentials, processing and settlement.
• Payment app/SDK — The installed certified payment application or SDK that performs secure card entry and processing.
• Provider adapter — A small application component encapsulating payment launch, result mapping, status lookup and supported cancellation.
• Gate — A decision checkpoint: Gate 1 supported route, Gate 2 test transaction demonstration, Gate 3 settlement verification, Gate 4 next-scope recommendation.
• Idempotency — A provider mechanism to prevent duplicate submission of the same request.
• Request ID — A unique application-generated identifier for each payment request.
• Unknown outcome — A transaction state where no reliable provider response is available; it remains unresolved until looked up or provider-assisted.
• Provider approval / local acceptance / bank settlement — Three distinct states that must not be conflated.
• PAN / CVV / PIN / OTP — Sensitive authentication data that must never be retained.

• PayDroid — The Android-based terminal OS for the provisional PAX A920Pro target.
• POSLink — A PAX development interface documented for Android/POS integration.
• PPR / login ID — A portal credential considered useful only if its issuing platform and authorization can be established.
• Pilot — A controlled live transaction executed only with provider and merchant authorization.
• Test matrix — The executed set of scenarios and their sanitized evidence.
• Sanitized evidence — Records with card/account information redacted, suitable for sharing.
• Proceed / Conditional / Stop — Outcome classifications: exact flow supported with settlement evidenced; integration demonstrated with approvals or settlement pending; requirement unsupported, access unavailable, or a critical test fails.