Operational documentation for provider-connected checkout, unified branding, payment method routing, Bring Your Own Gateway, provider integrations, API usage, webhooks, transaction metadata, reconciliation, risk controls, evidence records and technology partner responsibilities.
This Payment Orchestration Documentation is designed to be read together with the PayJSR Terms of Service, PayJSR Commerce & Supplier Addendum, PayJSR Privacy Policy, and PayJSR Buyer Terms, Buyer Protection, Refund, Delivery & Dispute Policy. These five documents are intended to form the core public legal and operational framework for PayJSR. This document does not create a standalone financial product, standalone payment processing service, deposit account, wallet, bank account, stored value account, money transmission service or payment facilitator program.
1.Purpose and scope
This document explains how PayJSR Payment Orchestration works as a technology, checkout, billing, branding, routing, API, data, evidence, reconciliation and operational infrastructure layer above approved payment providers, gateways, processors, acquirers, banks, wallets, mobile money providers, open banking providers, payout providers, fraud tools, identity tools, tax tools, communication tools and other third-party infrastructure providers.
The purpose of PayJSR Payment Orchestration is to allow approved sellers, suppliers, platforms and businesses to centralize the commerce experience inside the PayJSR ecosystem while the underlying authorization, acquiring, banking, settlement, card network, wallet, mobile money, payout, fraud, identity, tax or provider- controlled activity remains subject to the relevant provider, bank, payment network, regional structure and applicable law.
Payment Orchestration is a software and operational infrastructure function. PayJSR may provide the technology layer for checkout, provider connection, route configuration, event normalization, dashboard display, customer portal records, seller reporting, dispute evidence and reconciliation, but PayJSR does not assume provider, bank, acquirer, issuer, network, wallet, mobile money, payout provider or settlement obligations unless expressly agreed in writing, required by mandatory law, or expressly enabled through a PayJSR Commerce structure where a PayJSR entity acts as merchant of record or contracting merchant for an eligible transaction.
2.Five-document framework
PayJSR Payment Orchestration is operated within a five-document framework. The PayJSR Terms of Service govern the overall platform, accounts, acceptable use, risk controls, balances, payouts, reserves, API use, suspension, liability and dispute resolution. The PayJSR Commerce & Supplier Addendum governs seller and supplier participation in PayJSR Commerce, including product approval, fulfilment, supplier proceeds, holds, reserves, chargebacks and supplier responsibilities. The PayJSR Privacy Policy governs data, cookies, tokens, payment metadata, security, international transfers, privacy roles and data rights. The PayJSR Buyer Terms, Buyer Protection, Refund, Delivery & Dispute Policy governs checkout disclosures, buyer consent, buyer accounts, receipts, customer dashboard access, product-specific refund and delivery rules, internal disputes and buyer protection workflows. This document governs payment orchestration, provider connections, routing, BYO Gateway, webhooks, API controls, provider credentials, reconciliation and technology partner responsibilities. PayJSR does not need a separate public acceptable use policy, cookie policy, refund policy, BYO Gateway policy, PCI statement or seller onboarding policy for the core public framework because those topics are incorporated into the five documents. PayJSR may still maintain internal operating procedures, risk matrices, provider-specific requirements, underwriting checklists, data processing addenda, enterprise agreements, order forms, provider addenda or regional terms where needed.
3.PayJSR ecosystem position
PayJSR is a commerce, billing, hosted checkout and payment orchestration infrastructure platform. PayJSR provides the software layer for product creation, product pages, hosted checkout, payment links, subscriptions, buyer flows, customer portal, seller dashboard, provider connections, routing logic, webhook normalization, ledger records, reconciliation records, risk controls, refund workflows, dispute evidence, payout workflows and operational automation.
The PayJSR ecosystem is designed to centralize the seller and buyer experience. A seller may use one PayJSR dashboard, one checkout experience, one product record, one buyer flow, one order record, one customer portal, one API layer and one operational record while approved providers continue to perform the regulated or provider- controlled functions that they are authorized, licensed, registered, contracted or permitted to perform.
PayJSR does not replace gateways, processors, banks, card networks, mobile money operators, wallets, acquirers, open banking providers, payout providers, fraud providers, identity providers, tax providers or compliance providers. PayJSR connects to approved providers, routes through approved providers, records provider responses, standardizes events, supports reconciliation and presents a unified commerce experience.
4.Operating models
PayJSR may support different operating models depending on country, product category, seller approval, provider approval, payment method, risk level, settlement structure, payout rail, buyer location, supplier location and regional compliance pathway.
PayJSR Commerce. In PayJSR Commerce, an applicable PayJSR entity may act as merchant of record, contracting merchant, transaction-side merchant or commerce operator for eligible approved transactions. The buyer purchases through PayJSR checkout, PayJSR order flow, PayJSR buyer terms and PayJSR commerce infrastructure. The supplier remains responsible for the underlying product or service, including fulfilment, delivery, support, product claims, marketing claims, warranties, taxes and compliance.
Bring Your Own Gateway. In Bring Your Own Gateway, an approved seller connects its own provider accounts, payment providers, gateways, processors, wallets, bank rails, open banking providers or payout providers to PayJSR. PayJSR acts as a technical, checkout, billing, branding, routing, API and orchestration layer above providers controlled by the seller or approved for the seller. The seller remains responsible for its relationship with each provider and for compliance with each provider's terms.
Provider-connected orchestration. In provider-connected orchestration, PayJSR may connect to approved providers through APIs, hosted payment components, redirect flows, provider-managed vaults, tokenized payment methods, hosted pages, webhooks, settlement files, reconciliation files, dispute APIs, refund APIs, payout APIs or other supported integration methods. PayJSR may route transactions based on approved operational rules, but provider authorization, settlement, payout timing, chargeback timelines, provider restrictions and network rules remain subject to the provider and applicable law.
5.Technology partner role
PayJSR's role in Payment Orchestration is to provide technology and operational infrastructure. PayJSR may create or host checkout sessions, product pages, payment links, billing flows, subscription flows, customer portal records, seller dashboard records, API endpoints, webhook endpoints, event logs, transaction references, route records, risk flags, support records and reconciliation records.
PayJSR may centralize branding so the buyer sees a coherent PayJSR-hosted checkout or a seller-branded checkout powered by PayJSR. PayJSR may centralize the seller experience so the seller can manage products, providers, payment methods, orders, buyers, refunds, disputes, subscriptions and reporting from one dashboard instead of integrating each provider separately.
PayJSR may normalize provider events into internal statuses such as checkout created, payment initiated, authorization pending, authorized, captured, failed, cancelled, expired, settled, refunded, disputed, charged back, reversed, payout pending, payout paid, payout failed, hold created, reserve applied or review required. Internal statuses are operational records and do not replace the provider's official status, settlement file, payout confirmation, acquirer record, wallet record, bank record or network record.
6.No assumption of provider financial obligations
Unless expressly agreed in writing or required by mandatory law, PayJSR does not assume the financial, banking, acquiring, issuer, card network, wallet, mobile money, processor, payout provider, settlement provider, chargeback network, stored value, money transmission, deposit, trust, fiduciary or custodial obligations of any provider, seller, supplier, buyer, bank, acquirer, processor, card network, wallet provider, payout provider or other third party.
PayJSR is responsible for the software services, orchestration workflows, checkout technology, APIs, dashboard tools, provider connection tools, data handling, security controls and operational records that PayJSR expressly provides. Providers remain responsible for the regulated payment services, banking services, acquiring services, settlement services, payout services, wallet services, mobile money services, open banking services, fraud services, identity services, dispute services or other third-party services that they provide under their own rules and applicable law.
A PayJSR dashboard balance, provider reference, transaction status, routing record, payout workflow, reconciliation record or ledger entry is an operational record. It is not a bank account, deposit, stored value balance, e-money balance, trust account, investment account, custody account or unconditional right to immediate settlement.
7.Provider responsibility and third-party dependencies
Each provider may approve, reject, authorize, decline, delay, hold, freeze, refund, reverse, charge back, settle, audit, fine, suspend, terminate, restrict or otherwise control transactions, accounts, payment methods, settlement, payouts, disputes or provider relationships according to its own rules, risk decisions, banking partner requirements, payment network rules and applicable law.
PayJSR may route or retry eligible transactions through available providers based on country, currency, method, amount, provider availability, approval rates, risk, compliance, cost, route rules, fallback rules, provider uptime or other operational criteria. A routing decision does not guarantee authorization, settlement, payout, approval, refund success, chargeback outcome, provider availability or account continuity.
If a provider delays, holds, reverses, rejects, freezes, refunds, charges back, fines, audits, reviews, terminates or restricts a transaction, account, provider route or payout, PayJSR may mirror or pass through the impact to the seller or supplier, including by holding supplier proceeds, delaying payouts, requesting documents, disabling a provider route, changing route rules, increasing reserves, refunding buyers, pausing products, restricting accounts or terminating access where necessary.
8.Connected Provider and BYO Gateway responsibilities
A seller that connects a provider to PayJSR represents that the seller has the legal, contractual, provider- approved and technical right to connect that provider, share provider credentials, authorize API access, receive webhooks, request refunds, view provider data, display provider responses, reconcile transactions and use provider information through PayJSR.
The seller remains responsible for the seller's provider account, provider onboarding, provider underwriting, provider risk review, provider pricing, provider reserves, provider settlement, provider chargebacks, provider refunds, provider disputes, provider compliance requirements, provider account restrictions, provider termination and provider reporting obligations, except where PayJSR expressly controls a specific activity through a PayJSR Commerce structure or separate written arrangement.
PayJSR does not guarantee that a provider will approve a seller, maintain a seller account, approve a payment method, authorize a transaction, settle a transaction, release funds, support a payout rail, accept a refund, approve a chargeback response, maintain uptime, support a country, support a currency or continue to provide services.
PayJSR may disconnect, rotate, suspend, limit or disable any provider connection where PayJSR believes there is security risk, provider instruction, credential compromise, unauthorized connection, terms violation, fraud risk, compliance risk, excessive disputes, high chargeback exposure, misleading products, unsupported country, unsupported category or harm to PayJSR, buyers, providers, banks or networks.
9.Unified checkout and branding
PayJSR Payment Orchestration may allow buyers to experience one PayJSR-hosted checkout, one order flow, one receipt flow, one support flow and one customer dashboard even when multiple providers, routes or payment methods are available behind the scenes.
The checkout may show PayJSR branding, seller branding, product branding, payment method branding, provider-approved descriptors, seller support details, product-specific refund terms, delivery terms, buyer protection information and required legal disclosures where necessary for clarity, compliance, provider rules or chargeback prevention.
Before payment, the checkout should clearly disclose material product or service terms, including product name, description, total price, currency, taxes, fees, delivery method, delivery timeline, access method, cancellation rules, refund rules, subscription terms, seller support contact and any material limitations. PayJSR may require affirmative buyer consent to the Buyer Terms, Refund, Delivery & Dispute Policy, Privacy Policy, electronic communications, receipt delivery, Customer Dashboard access and internal dispute workflow.
After payment, PayJSR may send receipts, order confirmations, product access instructions, seller support details, refund or dispute notices and customer dashboard invitations using the email address provided at checkout.
10.Payment method and route controls
PayJSR may support routing by country, currency, payment method, provider, buyer location, seller location, transaction size, product category, risk level, provider availability, approval rate, fallback rules, cost, compliance requirement or business rule. Examples include routing a local South African payment method through an approved South African provider, routing a card transaction through an approved card acquirer or gateway, routing an open banking payment through an approved open banking provider, or routing a mobile money payment through an approved mobile money provider.
PayJSR may apply fallback routing only where provider rules, payment method rules, buyer consent, seller approval, technical availability and risk controls permit. PayJSR may disable fallback routing for restricted categories, high-risk products, unsupported methods, provider outages, compliance concerns, excessive declines, suspected fraud, abnormal refund ratios, elevated chargebacks, non-delivery indicators or provider restrictions.
PayJSR may change providers, disable providers, add providers, remove providers, route away from providers, change retry logic, change payment method presentation or change settlement workflows where necessary for risk, compliance, availability, pricing, performance, provider requirements, legal requirements or business operations.
11.Provider integrations, credentials and tokens
PayJSR may connect to providers through hosted payment pages, hosted fields, provider SDKs, redirect flows, APIs, OAuth, webhook endpoints, server-side tokens, provider tokens, client references, settlement references, refund APIs, dispute APIs, payout APIs or other approved integration methods.
PayJSR may store provider credentials, API keys, OAuth grants, access tokens, refresh tokens, webhook secrets, provider account IDs, merchant IDs, transaction references, customer IDs, payment method references, settlement references, refund references, dispute references and reconciliation metadata as necessary to operate the platform. PayJSR should protect such credentials using access control, encryption or equivalent safeguards appropriate to the risk and sensitivity of the credential.
Sellers and developers must not share provider credentials publicly, embed secret keys in frontend code, expose webhook secrets, reuse credentials across unapproved environments, bypass PayJSR security controls, connect providers in violation of provider terms, or use provider credentials for a business, product, country or payment method that was not approved.
12.No direct storage of sensitive card data
PayJSR is designed to use provider tokenization, hosted payment components, provider-managed vaults, redirect flows or equivalent secure payment architecture where supported. Unless PayJSR expressly states otherwise in writing, PayJSR does not directly store full card numbers, full magnetic stripe data, full EMV chip data, full card security codes, CVV or CVC codes, PINs, PIN blocks or sensitive authentication data on PayJSR servers.
PayJSR may store provider tokens, payment method references, transaction identifiers, authorization identifiers, customer identifiers, last four digits, card brand, expiry metadata, billing metadata, risk metadata, provider response data, webhook data, checkout status, refund status, dispute status, settlement status and reconciliation metadata necessary to operate checkout, subscriptions, refunds, disputes, risk review, customer support, routing and reconciliation.
Sellers, suppliers, developers and buyers must not send full card numbers, card security codes, bank credentials, PINs, sensitive authentication data or other restricted payment data to PayJSR through email, chat, support tickets, files, API metadata, product descriptions, dispute evidence or unapproved interfaces. If restricted payment data is sent improperly, PayJSR may delete it, mask it, quarantine it, restrict access, require remediation, notify providers, report where required or terminate access.
13.Webhooks, normalized events and technical evidence
PayJSR may receive webhooks, API responses, settlement files, dispute notices, refund confirmations, payout notices, provider status updates, failure codes, risk notices, fraud notices, chargeback records and other technical or operational records from connected providers. PayJSR may normalize those events into PayJSR internal events for dashboard visibility, seller notifications, buyer notifications, support, reconciliation, risk review, audit trails and evidence preservation.
PayJSR may require every transaction to include traceable metadata such as order number, checkout session ID, product ID, seller ID, supplier ID, wallet or ledger reference, buyer email, provider reference, currency, amount, payment method, route used, product type, delivery status, refund status, dispute status and risk metadata. This metadata allows PayJSR to identify the transaction, support the buyer, investigate disputes, hold supplier proceeds, respond to chargebacks, reconcile provider activity and maintain auditability.
Sellers and developers must not forge, alter, replay, suppress, delay, falsify or manipulate webhooks, checkout statuses, provider events or route records. PayJSR may reject events, require webhook signatures, rotate webhook secrets, rate-limit endpoints, pause integrations, suspend API access or terminate provider connections if PayJSR detects tampering, replay attacks, false events, duplicate events, suspicious event patterns or inconsistent provider responses.
14.Reconciliation, ledger and operational records
PayJSR may maintain internal records for checkout sessions, order numbers, provider references, buyer IDs, seller IDs, product IDs, payment statuses, refund statuses, dispute statuses, chargeback statuses, payout references, settlement dates, fee deductions, FX metadata, reserve records, hold records, reconciliation entries, evidence records and support records.
These records are designed for operational visibility, customer support, seller reporting, provider reconciliation, refund review, dispute evidence, compliance review, tax records, risk monitoring and platform protection. They are not a substitute for provider settlement files, bank statements, acquirer records, card network records, tax filings or legally required accounting records maintained by sellers, providers or banks.
If there is a conflict between a PayJSR dashboard record and an official provider settlement record, PayJSR may review and correct the internal record. PayJSR may adjust ledger entries, delay payout, request documentation, reverse incorrect entries or reconcile balances where provider data, bank data, refund data, dispute data, chargeback data or settlement data requires correction.
15.Settlement, payouts and provider outcomes
Provider settlement, payout timing and payment method availability may depend on provider rules, bank timelines, acquirer rules, card network rules, mobile money rules, wallet rules, settlement files, payout rail availability, country, currency, risk level, seller verification, product type, reserves, holds, refunds, chargebacks and applicable law.
PayJSR may display payout workflows, available balances, pending balances, holds, reserves, deductions, provider references and settlement estimates in the seller dashboard. These records are operational records only. They do not guarantee instant payout, immediate settlement, provider approval, bank approval, payout success, release of reserves or finality of funds.
PayJSR may delay, reduce, reverse, cancel, split, hold or reject a payout where PayJSR believes there is provider risk, legal risk, regulatory risk, fraud risk, buyer risk, chargeback risk, refund risk, tax risk, sanctions risk, AML risk, product risk, non-delivery risk, documentation risk, negative balance exposure, suspicious activity, provider review, buyer dispute, supplier non-response or violation of PayJSR terms.
16.Refunds, disputes, chargebacks and buyer protection
PayJSR may provide refund, cancellation, delivery review, dispute and chargeback workflows inside the PayJSR dashboard and Customer Dashboard. PayJSR may request evidence from sellers and suppliers, including proof of delivery, tracking numbers, access logs, download logs, license activation records, customer communications, invoices, product descriptions, checkout records, IP addresses, device information, consent records, subscription authorization, refund policy acceptance and support records.
In PayJSR Commerce, PayJSR may decide whether to refund, partially refund, deny a refund, hold funds, request seller evidence, respond to chargebacks, submit evidence, accept a chargeback, contest a chargeback or take protective action according to the PayJSR Terms, Supplier Addendum, Buyer Terms, provider rules, payment network rules, product category, delivery evidence and applicable law.
In Bring Your Own Gateway, provider-controlled disputes, bank disputes, payout reversals, chargebacks, refunds and settlement outcomes may remain under the seller's provider account. PayJSR may provide the technical dashboard, evidence trail, routing records, metadata and operational tools, but the provider, seller, bank or network may control the final financial outcome.
17.Risk review, product category controls and route restrictions
PayJSR may maintain risk review, fraud screening, transaction monitoring, sanctions screening, velocity checks, refund monitoring, dispute monitoring, chargeback monitoring, payout monitoring, device checks, IP checks, provider response monitoring, product risk review, delivery review, seller verification, buyer pattern review and other controls to protect buyers, sellers, suppliers, providers, banks, payment networks, PayJSR entities and the platform.
PayJSR may classify sellers, products, categories, countries, payment methods, providers and routes as approved, conditionally approved, restricted, prohibited, temporarily unavailable or manual review required. Approval to use PayJSR does not mean every provider, route, method, country, product, category or payout rail is available to every seller.
PayJSR may prohibit or restrict illegal products, deceptive offers, unauthorized financial services, money laundering, terrorist financing, sanctions evasion, counterfeit goods, stolen goods, fake documents, identity fraud, card testing, unauthorized card use, phishing, malware, hacking tools, illegal drugs, unlicensed medicine, unsafe products, weapons, gambling, betting, lotteries, pyramid schemes, get-rich-quick schemes, misleading investment products, adult sexual content or services, infringing products, products that cannot be fulfilled, false claims, excessive chargeback risk or any business PayJSR considers high risk, harmful, unlawful, misleading, reputationally damaging or incompatible with the platform.
PayJSR may require pre-approval, product review, provider approval, higher reserves, lower limits, delayed payouts, proof of delivery, proof of stock, supplier verification, licensing evidence, additional monitoring or written approval before enabling certain categories, countries, providers, payment methods or routes.
18.Seller, supplier and developer responsibilities
Sellers and suppliers remain responsible for their products, services, pricing, tax classification, product descriptions, fulfilment, delivery, customer support, refund policies, subscription terms, advertising claims, business model, customer communications, compliance obligations, provider approvals, provider accounts, connected credentials, chargeback exposure, refund exposure, negative balances, prohibited activity and all obligations under PayJSR terms, provider terms and applicable law.
Developers must use PayJSR APIs, webhooks, SDKs, checkout sessions, redirect URLs, provider connection tools, sandbox environments and production keys only in accordance with PayJSR documentation, security standards, provider rules, rate limits and applicable law.
Developers must not expose secret keys, bypass authentication, disable security controls, manipulate provider responses, forge checkout sessions, tamper with payment statuses, simulate fake sales, test stolen cards, overload systems, scrape data, access unauthorized accounts, interfere with other users, misuse webhooks or connect providers without authorization.
19.API, sandbox and production controls
PayJSR may provide APIs, developer tools, webhooks, sandbox environments, test modes, production keys and provider connection tools. Sandbox activity must be clearly separated from production activity. Test transactions must not be used to simulate real sales, inflate volume, mislead providers, trigger false conversion events or create fake settlement records.
Production API access may be limited by account status, product approval, provider approval, route approval, country, currency, payment method, risk level, transaction volume, dispute ratio, chargeback ratio, refund ratio, seller verification or provider requirements.
PayJSR may rotate, suspend, revoke, limit or disable API access, provider connections, webhook endpoints, checkout access or production keys at any time for security, risk, compliance, operational, provider or business reasons.
20.Data protection and privacy
PayJSR may process personal data, business data, transaction data, payment metadata, provider references, device data, IP addresses, risk data, buyer data, seller data, order data, support data, dispute evidence and technical logs as necessary to operate checkout, orchestration, provider connections, routing, reconciliation, security, fraud prevention, refunds, disputes, compliance, tax records, customer support, analytics and platform protection.
Depending on the context, PayJSR may act as an independent controller, responsible party, processor, operator, service provider, technology provider or similar role under applicable privacy laws. Sellers may also act as controllers or responsible parties for their own buyer data, marketing data, product data, support data and connected provider data.
PayJSR may share relevant data with providers, banks, processors, card networks, fraud providers, KYC providers, payout providers, tax providers, analytics providers, cloud providers, communication providers, regulators, law enforcement, courts, advisors or other third parties where necessary to provide the platform, comply with law, manage risk, process payments, handle disputes, prevent fraud or protect PayJSR.
21.Security responsibilities
PayJSR is responsible for maintaining reasonable technical and organizational controls for the PayJSR systems it operates, including access control, credential management, logging, monitoring, secure development practices, data minimization, encryption where appropriate, incident response, provider credential protection and platform abuse controls.
Sellers and developers are responsible for securing their own websites, applications, API keys, staff access, provider credentials, connected accounts, webhooks, domains, redirects, customer communications, product files, fulfilment systems and support workflows. Sellers must immediately notify PayJSR if they suspect unauthorized access, credential compromise, provider compromise, fraud, webhook abuse or security misuse.
Providers are responsible for the security of the provider systems they operate, including hosted payment pages, token vaults, authorization systems, settlement systems, dispute systems, payout systems and provider-managed payment credentials.
22.PCI, tokenization and shared responsibility
PayJSR's payment architecture is designed to reduce payment data risk by using approved providers, hosted payment components, secure provider interfaces, provider tokenization and provider-managed vaults where supported. PayJSR does not intentionally store full card numbers or CVV/CVC codes on PayJSR servers.
Outsourcing payment processing and using tokenization can reduce direct card data exposure, but it does not automatically remove all PCI DSS or payment security obligations. Sellers, suppliers, developers and PayJSR must understand and follow the responsibilities that apply to their own systems, provider relationships, checkout flows, APIs, credentials and payment environments.
PayJSR may require sellers, suppliers, developers and connected businesses to use approved provider integrations, secure redirect flows, hosted payment components, tokenized payment methods, encrypted transport, access controls, webhook signature validation, least-privilege permissions and other controls required by provider rules, card network rules, PCI DSS obligations and PayJSR security standards.
23.Regional activation and compliance pathways
Payment Orchestration may be activated country by country, entity by entity, provider by provider, product category by product category, seller by seller and payment method by payment method. PayJSR may require regional terms, provider approval, bank approval, sponsoring arrangements, local KYC/KYB, proof of licensing, proof of stock, proof of fulfilment, tax information, compliance review or a different operating structure before enabling a provider, method, route or payout rail.
South African operations may be subject to applicable South African laws, regulations, directives and provider requirements, including company, consumer protection, electronic communications and transactions, privacy, anti-money laundering, payment, banking, tax, cybercrime and payment network requirements. If any South African regulator, provider, bank, payment network or applicable rule requires registration, authorization, sponsoring bank registration, partnership with a licensed provider or a different structure for an activity, PayJSR may limit, suspend, restructure or enable that activity only through an appropriate compliant pathway.
United States and Delaware-related operations may be subject to applicable United States federal law, Delaware law, electronic contracting rules, commercial conduct rules, sanctions, AML-related controls, provider rules, payment network rules and state requirements. JSR Technologies, LLC is primarily the technology owner, software provider, platform infrastructure provider and IP licensor for PayJSR unless a separate compliant operating structure expressly enables another role.
Mozambique and other cross-border operations may be subject to local electronic transaction, e-commerce, privacy-related, cyber security, consumer protection, payment, tax, AML, sanctions, telecom, banking, provider and payment network requirements. PayJSR may restrict or activate specific methods or providers only when there is an appropriate provider-supported, bank-supported or legally appropriate pathway.
European Union and United Kingdom data or customers may involve GDPR, UK GDPR, electronic commerce, cookie, consumer protection, payment security, advertising, platform and provider requirements where applicable.
24.TPPP, payment facilitation and regulated activity boundaries
If any mandatory law, provider rule, bank requirement, payment network rule or regulator treats a proposed activity as regulated payment services, money transmission, stored value, banking, deposit-taking, acquiring, payment facilitation, TPPP activity, system operator activity, payment institution activity or another regulated function, PayJSR may decline, suspend, restructure or enable the activity only through a licensed provider, approved partner, registered structure, sponsoring arrangement, exempt structure or other legally appropriate pathway.
Nothing in this document should be interpreted as PayJSR promising to operate every payment method, provider, payout rail, wallet, mobile money method, country, seller category or product category in every market. PayJSR may restrict, delay or refuse activation where the required provider, bank, licensing, registration, compliance or risk pathway is not available.
25.Operational implementation controls
For provider confidence, PayJSR should implement the following operational controls across Payment Orchestration.
Every transaction should include order number, checkout session ID, product ID, seller ID, buyer email, provider reference, amount, currency, payment method, route used and product type.
Every provider integration should use secure credential storage, least-privilege access, webhook signature validation where available, production and sandbox separation, credential rotation and audit logging.
Every checkout should show product terms, seller identity or support identity where needed, total price, delivery terms, refund terms, privacy links, buyer terms, product-specific rules and electronic consent.
Every refund or dispute should connect the buyer claim, seller evidence, provider reference, delivery evidence, access logs, support communications, transaction status and supplier proceeds hold where applicable.
Every route should be configurable by country, currency, method, provider, risk level, product category, account status and compliance status.
Every restricted product or category should require manual approval, stronger evidence, delayed payout, reserves, restricted methods or route limitation.
Every provider response should be logged and normalized without overwriting the provider source record.
Every incident involving card data, credentials, provider keys, webhook secrets, unauthorized access or abnormal activity should trigger containment, investigation, remediation and notification where required.
26.Audit, records and evidence retention
PayJSR may retain records for provider reconciliation, legal defence, tax records, security review, risk review, refund handling, dispute handling, chargeback response, buyer support, seller reporting, regulator requests, provider requirements and platform protection.
Evidence records may include checkout session IDs, order numbers, product IDs, seller IDs, buyer emails, provider references, payment method metadata, route decisions, access logs, download logs, delivery records, tracking numbers, refund requests, support communications, dispute evidence, provider notices, webhook events, settlement files, payout records and internal review notes.
PayJSR may preserve records after account closure, product removal, provider disconnection, payout completion or termination where PayJSR reasonably believes records are needed for refunds, chargebacks, disputes, provider claims, tax matters, legal claims, fraud prevention, sanctions review, AML review, security review or compliance obligations.
27.Suspension, limitation and termination
PayJSR may suspend, restrict, limit, remove or terminate any orchestration route, provider connection, checkout flow, seller account, product, payment method, payout workflow, API key, webhook endpoint, buyer flow, subscription or dashboard feature immediately where PayJSR believes there is fraud, security risk, provider risk, legal risk, regulatory risk, tax risk, sanctions risk, AML risk, excessive refunds, excessive chargebacks, buyer complaints, non-delivery, misleading marketing, prohibited activity, false information, credential compromise, provider instruction, business risk or harm to PayJSR, buyers, sellers, suppliers, providers, banks or payment networks.
Termination or suspension of Payment Orchestration does not remove the seller's responsibility for refunds, chargebacks, disputes, negative balances, provider fees, buyer claims, taxes, fulfilment, legal claims, provider obligations or any other obligations that arose before or after termination.
28.Changes to this documentation
PayJSR may update this Payment Orchestration Documentation at any time to reflect changes in law, provider requirements, payment network rules, security standards, product capabilities, dashboard workflows, API features, routing logic, risk standards, business operations, regional availability or compliance requirements. Continued use of PayJSR Payment Orchestration, provider connections, API access, BYO Gateway, checkout routing or related functionality after an updated version becomes effective means the user accepts the updated documentation, except where mandatory law requires a different process.
29.Contact and operational ownership
Questions about Payment Orchestration, provider integrations, API access, webhooks, routing rules, compliance review, buyer flows, seller onboarding, disputes or provider requirements may be sent to support@payjsr.com. Business and partnership enquiries may be sent to partners@payjsr.com.
Payment Orchestration must be operated together with the PayJSR Terms of Service, PayJSR Commerce & Supplier Addendum, PayJSR Privacy Policy, PayJSR Buyer Terms, Buyer Protection, Refund, Delivery & Dispute Policy, provider rules, payment network rules, regional terms and any separate written agreement or approval issued by PayJSR.
This page reproduces the PayJSR Payment Orchestration Documentation. PayJSR provides commerce, billing, checkout and payment-orchestration technology and is not a bank. Services described are available for approved accounts and are subject to provider availability, compliance review and applicable law. For questions, contact support@payjsr.com.