PEYELI — PARTNER EVALUATION BRIEF Edition 1.3 · reviewed 11 October 2026. Evaluation material only; no agreement, access grant, provider approval or release certification. Find your place in the network. ============================================================ Find the opportunity that fits your organization: collections, settlement, remittance, card programs or connected software. The relationship determines the scope. Peyeli owns the software experience and its operational records. A financial provider’s responsibilities depend on the approved agreement: collection, custody, settlement, remittance or issuance. A technical connection does not transfer those responsibilities automatically. Partner model | What we evaluate | What needs agreement Collections / FSP | Merchant requests, authenticated results, lookup and settlement. | Merchant delegation, assets, fees, refunds and settlement authority. Bank / settlement | Statements, deposit matching, exceptions and evidence. | Account ownership, data rights, formats and resolution responsibilities. Remittance | Hosted customer journey, identity handoff and status authority. | Corridors, platforms, disclosures, compliance and payout methods. Card issuer / sponsor | Program, funding, authorization, clearing and refunds. | Eligible regions, cardholder requirements, funding and program controls. Accounting / software | Consented record exchange, mapping and recovery. | Objects, read/write permissions, retention and disconnect behavior. Turn the opportunity into a working relationship. An evaluation needs an authorized technical specification and test access. We also need to establish who can act for each merchant, which customer types and countries are eligible, what proves an outcome, and who handles disputes or settlement differences. - Identify the contracting entity, program and environment. - Confirm lookup, duplicate handling, reversals and settlement evidence. - Agree on incident contacts, test limits and acceptance criteria. Make the next conversation concrete. ============================================================ Turn interest into a concrete working session: define the opportunity, choose a scope and agree on what a successful test will show. Begin with a defined use case. Describe the financial or software operation you want to enable, who initiates it, who benefits, and which institution is authoritative. Identify countries, customer residency, currencies, merchant model and expected volumes without supplying customer data. - Identify your organization, product and proposed role. - State the exact operation and customer/merchant scope. - Supply authorized technical documentation and test prerequisites. Prove both success and recovery. Agree on a written test matrix before activation. Use synthetic identities and bounded authorized provider test operations. Record observed provider evidence separately from fixture tests. A return screen or successful HTTP response is insufficient proof of financial completion. - Success, rejection, pending and timeout after submission. - Duplicate request/event, invalid signature and mismatched amount/account. - Late confirmation, lookup outage, reversal and settlement difference. - Cross-tenant denial, access expiry, revocation and disabled capability. - Compatible deployed client/API/schema and agreed operational recovery. Leave with a bounded decision. The evaluation outcome should name what passed, what remains open, the exact environment and permitted operations, who approves the next stage, and how access expires or is revoked. A successful evaluation is not automatic production approval. Use the downloadable brief to prepare your review. It is a checklist, not an agreement or an access grant. Start public. Grant deliberately. ============================================================ A proposed staged evaluation policy that keeps documentation access separate from application and financial permissions. Four stages of access These are evaluation policy stages, not implemented OAuth scopes or an automatic provisioning service. Exact technical access must be reviewed against the selected deployment. Stage | Permitted evaluation | Boundary Public reader | Curated documentation and synthetic examples. | No account or record access. Guided demo | Named users, isolated synthetic tenant; read-only first. | Explicit simulation actions only; no privileged shared login. Approved sandbox | Specific organization, operations, assets and test volume. | Time-limited, revocable test access; no production funds. Pilot / live | Separately approved program and reviewed release. | Agreement, acceptance and operational ownership required. Define the grant before sharing access. Record the named users and organization, business purpose, environment, permitted operations, assets/currencies, merchant/provider boundaries, duration, limits, owner, approver and revocation procedure. Verify denied access as carefully as permitted access. - No source repository, infrastructure console or production access by default. - No other merchant’s records, customer KYC or raw payment payloads. - No wallet issuance, payout, FX, refunds or card authority implied by collection access. - Expire and revoke access through a verified procedure. Next step: use the existing Peyeli contact page to arrange a scoped evaluation. Do not send credentials or customer records.