Exact flow eligibility
Documented provider interface defining the requested operation and the supported integration contract.
offline-pos-proposal
by
Janvi shah
Janvi shahNeed a proposal for the below scope of work attached
Comments (0)
Sign in to leave a comment
Architecture
No Services Diagrams Yet
fxis.ai
POS POC — Nijo G Sabu
fxis.ai · POS POC proposal · Section 01
We will only call it proven when the terminal, the provider and the bank agree
- fxis.aiintegrator and POC implementation lead
- Nijo G Sabumerchant and proposal sponsor
- PAX A920Proprovisional target terminal (PayDroid / Android)
- Indian Overseas Banknominated settlement account
Scope boundary
One merchant, one selected terminal, one provider and one agreed transaction flow. Execution runs on small approved amounts and one enabled currency.
Eligibility for EUR, USD and GBP is assessed separately and is not assumed.
Evidence half · gated execution07 stages
Four decision gates establish what is supported, demonstrated, settled and recommended next.
- 01Scope boundary
- 02Gate 1 · Device assessment
- 03Provider validation
- 04Gate 2 · Test transaction
- 05Target transaction sequence
- 06Gate 3 · Settlement verification
- 07Gate 4 · Next-scope recommendation
- Operation201.3
- Valuesix-digit value
- TargetPAX A920Pro
01Scope boundary
Questions this POC must resolve
four open questions · evidence list- 01Terminal access, provisioning and new-application useq1 · status open
- 02Exact operation 201.3, six-digit value and remote card entryq2 · status open
- 03Reliable results and uncertain-outcome recovery without duplicate submissionq3 · status open
- 04Approved pilot reconciled to the IOB account creditq4 · status open
What the POC will and will not cover
The POC is bounded to one merchant, one selected terminal, one provider and one agreed transaction flow. Execution runs on small approved amounts under a single enabled currency so financial exposure stays controlled.
Eligibility for EUR, USD and GBP is assessed separately rather than assumed. PAX A920Pro is the provisional target; another existing terminal is considered only where the provisional target proves unsuitable, and only subject to agreement on any resulting effort change.
- Scope boundaryone merchant · one selected terminal · one provider · one agreed transaction flow
- Execution amountssmall approved amounts · one enabled currency only
- Currency eligibilityEUR / USD / GBP assessed separately
- Provisional targetPAX A920Pro — alternative existing terminal considered only subject to agreement on any effort change
Unsupported capabilities and pending approvals are recorded explicitly. Where the evidence stops, the proposal says so rather than overstating the outcome.
02 – 07 · Gated execution
The gated process, as an index
Seven numbered stages run the POC from scope boundary to verdict. Dependent work proceeds only when the prior gate records a compatible route and the exact transaction capability; otherwise it pauses with the missing evidence listed. Each stage opens its own destination.
- 01Decision gateScope boundaryAssessment →One merchant, one selected terminal, one provider, one agreed transaction flow.
- 02Gate 1 · pendingSupported-route assessmentAssessment →Device and provider route assessed; proceed, pause or stop on documented evidence.
- 03Decision gateProvider validationProvider Validation →Operation 201.3, limits, currencies and settlement route confirmed as supported or unsupported.
- 04Gate 2 · pendingTest transaction demonstrationIntegration Setup →Test integration demonstrates the supported transaction flow with QA evidence.
- 05Decision gateTarget transaction sequenceCheckpoints →Secure interface, request ID handling and verified provider result demonstrated.
- 06Gate 3 · pendingSettlement verificationSettlement →Settlement compared with the actual IOB credit, or explicitly recorded as unverified.
- 07Gate 4 · pendingNext-scope recommendationFindings →Proceed, conditional or stop, with the evidence that supports it.
Handover of findings, POC source and build notes is recorded against the final gate at /handover. Gate status is the single source of truth; an unresolved outcome is held as unknown rather than reported as established.
05 · Evidence & deliverables
What we will hand over, and the evidence behind every line
This appendix is deliberately the densest part of the proposal: the deliverable ledger records what will be produced, and the test list records what each item must be able to prove. Nothing on this page is asserted as achieved until its evidence exists.
Required test evidence
App invocation
Kotlin application invokes the certified app or SDK through the documented provider interface.
Successful payment
Verified provider result and reference mapped to the request ID; six-digit value handled per confirmed classification and provider rules.
Rejection handling
Declined or rejected result recorded without any local success state being shown.
Duplicates and timeout
Single active request enforced; timeout leaves the outcome recorded as unknown, never re-submitted.
Restart and offline
Restart and offline behaviour observed; recovery directs the operator to the original request.
Receipt and security
Receipt print and reprint treated as non-charging actions; sanitized screens carry no PAN, CVV, PIN or OTP.
Live settlement
Approved pilot reconciled against the Indian Overseas Bank account credit, or recorded as pending.
Deliverable ledger
Six items constitute the POC handover. Each carries the form in which its evidence is recorded.
| No. | Deliverable | Evidence form |
|---|---|---|
| 01 | Device inventory and Gate 1 checkpoint report | Model, OS and firmware baseline |
| 02 | Provider validation of operation, limits, currencies and settlement route | Operation, limits, currencies, settlement route |
| 03 | Test integration demonstration with QA evidence | QA evidence, sanitized |
| 04 | Controlled live pilot reconciliation or documented pending status | Reconciliation or documented pending status |
| 05 | Executed test matrix with sanitized evidence | Sanitized evidence per test |
| 06 | Findings, POC source, build notes and next-scope recommendation | Build notes, source, next-scope recommendation |
Active execution14–21 working days
Elapsed3–5 working weeks, prerequisites ready
Assessment checkpointFirst 2–3 days
External waitingAdditional · owner and expected response date recorded; reforecast at each checkpoint
07 — Verdict
Proceed
ConditionalStopOne of these three outcomes closes the proof of concept. Each is recorded against the evidence actually obtained — never against what the demonstration appeared to show.
PROCEED01
The exact transaction flow is supported and evidenced: operation 201.3 and the six-digit value succeed through the approved provider interface, results are returned reliably without duplicate submission, and an approved pilot settles as a credit to the nominated Indian Overseas Bank account.
CONDITIONAL02
Integration is demonstrated but one or more approvals or the settlement confirmation is still pending. The demonstrated portion is evidenced; the pending portion is recorded as pending rather than assumed, with the owner and expected response date attached.
STOP03
The requirement is unsupported by the provider, the required terminal access or information is unavailable, or a critical test has failed. The completed assessment and the blocker evidence are handed over; integration is not described as completed.
R1Critical payment-result defects or any evidence of duplicate charging prevent a proceed recommendation, regardless of how much of the flow is demonstrated.
R2If the POC is stopped early, the completed assessment and the blocker evidence are delivered. No part of the integration is described as completed.
Production readiness is not an acceptance criterion for this POC. The client review step confirms the recorded outcome and the agreed next step.
fxis.ai
POS POC — Nijo G Sabu
fxis.ai · POS POC proposal · Section 01
We will only call it proven when the terminal, the provider and the bank agree
- fxis.aiintegrator and POC implementation lead
- Nijo G Sabumerchant and proposal sponsor
- PAX A920Proprovisional target terminal (PayDroid / Android)
- Indian Overseas Banknominated settlement account
Scope boundary
One merchant, one selected terminal, one provider and one agreed transaction flow. Execution runs on small approved amounts and one enabled currency.
Eligibility for EUR, USD and GBP is assessed separately and is not assumed.
Evidence half · gated execution07 stages
Four decision gates establish what is supported, demonstrated, settled and recommended next.
- 01Scope boundary
- 02Gate 1 · Device assessment
- 03Provider validation
- 04Gate 2 · Test transaction
- 05Target transaction sequence
- 06Gate 3 · Settlement verification
- 07Gate 4 · Next-scope recommendation
- Operation201.3
- Valuesix-digit value
- TargetPAX A920Pro
01Scope boundary
Questions this POC must resolve
four open questions · evidence list- 01Terminal access, provisioning and new-application useq1 · status open
- 02Exact operation 201.3, six-digit value and remote card entryq2 · status open
- 03Reliable results and uncertain-outcome recovery without duplicate submissionq3 · status open
- 04Approved pilot reconciled to the IOB account creditq4 · status open
What the POC will and will not cover
The POC is bounded to one merchant, one selected terminal, one provider and one agreed transaction flow. Execution runs on small approved amounts under a single enabled currency so financial exposure stays controlled.
Eligibility for EUR, USD and GBP is assessed separately rather than assumed. PAX A920Pro is the provisional target; another existing terminal is considered only where the provisional target proves unsuitable, and only subject to agreement on any resulting effort change.
- Scope boundaryone merchant · one selected terminal · one provider · one agreed transaction flow
- Execution amountssmall approved amounts · one enabled currency only
- Currency eligibilityEUR / USD / GBP assessed separately
- Provisional targetPAX A920Pro — alternative existing terminal considered only subject to agreement on any effort change
Unsupported capabilities and pending approvals are recorded explicitly. Where the evidence stops, the proposal says so rather than overstating the outcome.
02 – 07 · Gated execution
The gated process, as an index
Seven numbered stages run the POC from scope boundary to verdict. Dependent work proceeds only when the prior gate records a compatible route and the exact transaction capability; otherwise it pauses with the missing evidence listed. Each stage opens its own destination.
- 01Decision gateScope boundaryAssessment →One merchant, one selected terminal, one provider, one agreed transaction flow.
- 02Gate 1 · pendingSupported-route assessmentAssessment →Device and provider route assessed; proceed, pause or stop on documented evidence.
- 03Decision gateProvider validationProvider Validation →Operation 201.3, limits, currencies and settlement route confirmed as supported or unsupported.
- 04Gate 2 · pendingTest transaction demonstrationIntegration Setup →Test integration demonstrates the supported transaction flow with QA evidence.
- 05Decision gateTarget transaction sequenceCheckpoints →Secure interface, request ID handling and verified provider result demonstrated.
- 06Gate 3 · pendingSettlement verificationSettlement →Settlement compared with the actual IOB credit, or explicitly recorded as unverified.
- 07Gate 4 · pendingNext-scope recommendationFindings →Proceed, conditional or stop, with the evidence that supports it.
Handover of findings, POC source and build notes is recorded against the final gate at /handover. Gate status is the single source of truth; an unresolved outcome is held as unknown rather than reported as established.
05 · Evidence & deliverables
What we will hand over, and the evidence behind every line
This appendix is deliberately the densest part of the proposal: the deliverable ledger records what will be produced, and the test list records what each item must be able to prove. Nothing on this page is asserted as achieved until its evidence exists.
Required test evidence
Exact flow eligibility
Documented provider interface defining the requested operation and the supported integration contract.
App invocation
Kotlin application invokes the certified app or SDK through the documented provider interface.
Successful payment
Verified provider result and reference mapped to the request ID; six-digit value handled per confirmed classification and provider rules.
Rejection handling
Declined or rejected result recorded without any local success state being shown.
Duplicates and timeout
Single active request enforced; timeout leaves the outcome recorded as unknown, never re-submitted.
Restart and offline
Restart and offline behaviour observed; recovery directs the operator to the original request.
Receipt and security
Receipt print and reprint treated as non-charging actions; sanitized screens carry no PAN, CVV, PIN or OTP.
Live settlement
Approved pilot reconciled against the Indian Overseas Bank account credit, or recorded as pending.
Deliverable ledger
Six items constitute the POC handover. Each carries the form in which its evidence is recorded.
| No. | Deliverable | Evidence form |
|---|---|---|
| 01 | Device inventory and Gate 1 checkpoint report | Model, OS and firmware baseline |
| 02 | Provider validation of operation, limits, currencies and settlement route | Operation, limits, currencies, settlement route |
| 03 | Test integration demonstration with QA evidence | QA evidence, sanitized |
| 04 | Controlled live pilot reconciliation or documented pending status | Reconciliation or documented pending status |
| 05 | Executed test matrix with sanitized evidence | Sanitized evidence per test |
| 06 | Findings, POC source, build notes and next-scope recommendation | Build notes, source, next-scope recommendation |
Active execution14–21 working days
Elapsed3–5 working weeks, prerequisites ready
Assessment checkpointFirst 2–3 days
External waitingAdditional · owner and expected response date recorded; reforecast at each checkpoint
07 — Verdict
Proceed
ConditionalStopOne of these three outcomes closes the proof of concept. Each is recorded against the evidence actually obtained — never against what the demonstration appeared to show.
PROCEED01
The exact transaction flow is supported and evidenced: operation 201.3 and the six-digit value succeed through the approved provider interface, results are returned reliably without duplicate submission, and an approved pilot settles as a credit to the nominated Indian Overseas Bank account.
CONDITIONAL02
Integration is demonstrated but one or more approvals or the settlement confirmation is still pending. The demonstrated portion is evidenced; the pending portion is recorded as pending rather than assumed, with the owner and expected response date attached.
STOP03
The requirement is unsupported by the provider, the required terminal access or information is unavailable, or a critical test has failed. The completed assessment and the blocker evidence are handed over; integration is not described as completed.
R1Critical payment-result defects or any evidence of duplicate charging prevent a proceed recommendation, regardless of how much of the flow is demonstrated.
R2If the POC is stopped early, the completed assessment and the blocker evidence are delivered. No part of the integration is described as completed.
Production readiness is not an acceptance criterion for this POC. The client review step confirms the recorded outcome and the agreed next step.
No comments yet. Be the first!