SAMFPayby Swiss AMF AG
Payment Gateway & OrchestrationStandalone Payment Gateway Software
Bring pay-ins, orchestration and payouts together under your brand. Start with ready-developed gateway technology, configured for your operation.
Standalone software, separate from SAMFCore and independently licensed.
Commercial availability, white-label and licensing rights are subject to final contractual authorisation.
01 / More business. Less rebuilding.
An internal build means developing and maintaining checkout, routing, provider connections and operational controls. Licensing existing software lets your team focus its engineering effort on configuration, integrations and your own proposition.
Build around your merchant relationships and chosen payment partners.
Configure provider priorities, fee rules and approval workflows within the agreed scope.
Start from existing software rather than developing every gateway capability internally.
Build: Design and implement the gateway infrastructure.
License: Start from ready-developed software, then configure and integrate.
Build: Depends on engineering scope, testing and provider access.
License: Focus implementation on the agreed deployment and integration scope.
Build: Budget for development, infrastructure and ongoing engineering.
License: Agree software licensing, implementation and ongoing service costs.
Build: Develop and validate checkout and outgoing payment workflows.
License: Review available workflows and confirm the required connectors.
Build: Build rules, retries, connector health and failover handling.
License: Configure the supported orchestration capabilities.
Build: Design and maintain APIs, webhooks and developer resources.
License: Use the available API layer and agreed developer resources.
Build: Resource continuous maintenance and security work internally.
License: Agree optional maintenance and support; operational responsibilities remain.
Build: Assemble resources for the complete development lifecycle.
License: Allocate resources to configuration, integrations, testing and operations.
Build: Develop changes within your own codebase.
License: Brand and configure the platform; scope optional custom development.
Build: Control code developed under your own IP arrangements.
License: Discuss proposed source-code access and modification rights, subject to authorisation.
Costs and timing depend on scope. Licensing does not remove testing, implementation or operational responsibilities.
Launch a branded gateway proposition without developing the entire operating infrastructure internally.
Introduce or expand payment acceptance and orchestration capabilities around your provider relationships.
Develop a branded gateway proposition while maintaining direct merchant relationships.
Add payment acceptance and payout workflows to existing financial technology products through agreed integrations.
Embed supported payment workflows into customer platforms and marketplace operations.
Offer available cryptocurrency checkout alongside other supported payment methods.
Review opportunities to improve routing, monitoring, fallback behaviour and provider connectivity.
02 / See the software
See the supplied SAMFPay interfaces for routing, transaction monitoring, payouts, checkout and AI insights. Discuss your own workflows in a live demonstration.
Illustrative software interface · example data, not live processing results.
Explore pay-ins, routing, payouts and merchant operations in a unified view.
03 / Three connected engines
A dedicated software layer connects the customer experience, your payment providers and the operations team.
Offer customers payment choices through a consistent checkout and API layer.
Manage provider selection and fallback behaviour through configurable rules.
Coordinate outgoing payments with operational controls and approvals.
PAYMENT FLOW
Configure priorities and eligible fallback paths between connected gateways. Routing criteria, retries and connector-health checks give operators control over how payment attempts are handled.
Illustrative routing example · not live processing
01 / INCOMING
Customer checkout
02 / ORCHESTRATION
SAMFPay rules
Ready to route
Only eligible attempts follow the configured fallback path. Retrying, cascading and the final outcome depend on the transaction, connector and provider rules; a failed payment is not automatically recoverable.
Processing outcomes depend on transaction and provider rules; no approval-rate increase is guaranteed. Payment methods and connectors must be confirmed for your configuration. Providers require separate commercial agreements.
04 / Your brand. Your level of control.
White-label presentation, configurable workflows and optional technical development let you shape a gateway around your business. Explore the proposed long-term licensing options with Swiss AMF AG.
Your logo, colours, domain and merchant-facing checkout.
Connections, routing, fees, permissions and approval workflows.
Scope APIs, additional integrations and custom development; code-based changes require licensed rights.
Proposed licensing option
Discuss long-term software usage, branded deployment, agreed modules and optional maintenance.
Proposed licensing option
Discuss source-code access, modification and deployment rights for a more independent engineering roadmap.
Commercialisation, white-label, perpetual and source-code rights require final contractual authorisation. The agreed licence defines usage, hosting, modules, modifications and support. The underlying IP belongs to a third-party technology owner; source-code access does not transfer copyright or confer unrestricted sublicensing rights.
05 / Practical product depth
Explore checkout experiences, operational controls and supported AI workflows without losing sight of the people running your payments business.
A consistent checkout helps customers move from payment selection to confirmation, using the required connected providers.
USDT checkout includes network selection, a payment QR code and on-chain confirmation. Ethereum ERC-20, Tron TRC-20, BNB BEP-20, Solana and Polygon must be confirmed for the delivered configuration and required integrations.
Transaction search, success/failure status, throughput and connector-health views help teams investigate payment issues. Lifecycle records, settlement information, webhook tracking and refund management support follow-up.
Manage beneficiaries, bank and supported crypto-wallet payouts, bulk requests and maker-checker approval workflows. Payout requests pass through configured checks and connected providers before the beneficiary/status response.
Review anomaly detection, approval trends, fraud patterns, routing recommendations, revenue forecasting and churn analysis within the supported AI scope. A support assistant can work with supported documentation, operating rules and transaction information.
Integration prompts, developer resources and supported coding tools assist engineers; they do not automatically complete an integration. Engineering review and testing remain required. AI data access and availability are confirmed for your scope; recommendations do not guarantee outcomes.
06 / From discovery to operation
Start with your markets, provider relationships and operating model. Agree the scope, validate the configuration and prepare your team for operation.
Define target markets, payment methods, provider access, business requirements and technical architecture.
Prepare your brand, access controls, fee rules, operating workflows and integration requirements.
Connect agreed providers, configure routing and validate payment, payout and webhook workflows.
Complete deployment, user acceptance testing, team training and go-live preparation.
Arrange monitoring, maintenance and support, then plan additional integrations and functionality.
Timing depends on integration complexity, provider access, testing and applicable approvals; no fixed launch period is guaranteed.
Assess the implementation against relevant PCI DSS, ISO 27001, SOC 2, GDPR and data-localisation requirements. These software controls support an assessment; they are not certification or a guarantee of compliance.
SAMFPay is separate software, not a payment processor, acquirer or permission to process payments. Customers remain responsible for applicable regulatory authorisations, acquiring, banking and payment-provider agreements.
07 / Details for your decision
SAMFPay is standalone payment gateway and orchestration software for branded gateway operations. Swiss AMF AG is the commercial contact. It is software infrastructure, not a payment-processing service or an acquirer; commercial availability is subject to the licensing terms described below.
Yes. SAMFCore is the comprehensive banking, payments, cryptocurrency and fintech platform. SAMFPay is a separate, dedicated gateway and orchestration product. It is not presented as an included SAMFCore module or a confirmed technical integration.
SAMFPay is intended to be licensed independently. A SAMFCore purchase is not part of the proposed SAMFPay offer. Availability and the exact licensed scope are subject to the final commercial agreement.
The proposed offer supports a gateway under your own brand, with agreed branding, configuration and integrations. You retain your customer relationships. Software usage rights do not transfer the underlying intellectual property or replace any required provider agreements or authorisations.
The platform supports cards with 3-D Secure, UPI, net banking, digital wallets and USDT checkout, alongside bank and crypto-wallet payouts and supported PayPal payouts. Each method must be confirmed against the delivered product, connector availability, target market and provider agreement.
USDT checkout covers network selection, QR-code payment and on-chain confirmation on Ethereum (ERC-20), Tron (TRC-20), BNB Smart Chain (BEP-20), Solana and Polygon. Network availability must be confirmed for your delivered configuration and required integrations.
Orchestration coordinates payment attempts across connected gateways using configured routing priorities, eligibility rules, retries and failover. It can help operations respond to provider issues; it does not guarantee a particular approval rate or successful processing of every payment.
Bring your existing provider list to the discovery discussion. Available connectors and any additional engineering will be assessed for your configuration. Acquirers, banks and payment providers require their own commercial agreements; no universal compatibility is promised.
The contract must define software modules, deployment scope, authorised usage, integrations and any support services. No unlimited merchant, entity, brand, transaction or territory rights are assumed. Pricing and limits are not yet published.
Perpetual software licensing and perpetual licensing with source-code access are proposed configurations, not confirmed entitlements. Commercialisation, white-label, hosting, deployment and modification rights require final contractual authorisation. The underlying technology and IP belong to a third-party technology owner, not Swiss AMF AG. The final licence must expressly define the rights granted; source-code access does not transfer copyright or confer unrestricted sublicensing rights.
The proposed source-code option is for teams seeking greater control of integrations and technical development. Actual access, permitted modifications and deployment scope must be expressly granted in the final authorised contract.
The proposed scope includes branding and operational configuration, with optional development for additional integrations and workflows. Code-based modification depends on the rights granted in the agreed licence. Scope, cost and delivery are quoted per engagement.
A launch plan follows discovery, configuration, integration testing and go-live preparation. Timing depends on your requirements, engineering complexity, provider access and applicable approvals. A delivery schedule is agreed for your scope; no fixed implementation period is guaranteed.
Controls include AES-256 encrypted API modes, plain or encrypted webhooks, two-factor authentication, login alerts and session termination, Administrator, Finance Manager, Support Agent and Read Only roles, payout approvals, velocity controls, fraud filters and audit-related monitoring. These controls are not evidence of PCI DSS, ISO 27001 or SOC 2 certification, nor a guarantee of GDPR compliance.
Where required for your business model and markets, yes. SAMFPay is software, not an acquiring bank, settlement service or regulatory authorisation. Customers remain responsible for the necessary permissions and acquiring, banking and payment-provider relationships.
Optional maintenance, support and custom development can be discussed with Swiss AMF AG and documented in an agreed engagement. Services, response commitments, upgrade access and prices must be defined contractually; none are assumed to be included.
Use Book a SAMFPay Demo to open the existing Swiss AMF AG booking page. Mention SAMFPay and your payment methods, markets and existing providers so we can plan a relevant demonstration and confirm software availability and licensing scope.
08 / The next step
Bring your markets, payment methods and provider priorities to a live conversation. See the software and discuss the licensing scope that would fit your business.
Prefer to start with an enquiry? Only your name and business email are required.
A standalone gateway and orchestration software proposition, independently licensed from SAMFCore. Your discussion stays focused on SAMFPay.
