When a merchant asks your software company, POS dealership, or technology team about accepting payments, the conversation often extends beyond a processing rate.
Will a terminal work with the POS? Is the gateway supported? Who handles tokenization? Where do settlement reports come from? And who gets the support call when something goes wrong?
Valued Merchant Services explores POS referral partnerships with qualifying technology businesses that want to connect merchants with payment processing and appropriate payment solutions.
Referral eligibility, integrations, software compatibility, development responsibilities, and compensation are reviewed individually.
POS referral partnerships are arrangements in which qualifying point-of-sale dealers, software firms, developers, or technology providers introduce interested business customers to a merchant services provider.
With VMS, an approved relationship may give technology businesses a defined process for introducing payment needs while maintaining their own software and customer relationships. However, the referral should not imply a supported integration where none has been verified.
For example, a standalone terminal may work for one merchant while another requires a supported POS connection, gateway-based checkout, or custom API workflow. The first question is not simply how to integrate. It is what the merchant needs payments to do.
A merchant's existing technology determines which payment options deserve consideration. These diagrams illustrate general payment patterns, not VMS-certified integrations or product commitments.
A merchant enters or confirms a payment using a separate payment terminal. Its business software may not communicate directly with the device.
Why it matters: This may avoid a new software integration. However, the merchant may need separate reporting and reconciliation procedures.
The POS initiates or coordinates payments through supported software, hardware, gateways, or other approved interfaces.
Why it matters: Device models, integrations, versions, certification, and required payment functions must be checked.
The customer's website uses a provider-hosted checkout or eligible embedded payment component. Implementation details determine the actual security scope.
Why it matters: Developers should evaluate checkout behavior, callback handling, order-state updates, and applicable PCI duties.
Software may use documented gateway APIs for supported transactions, payment status, or authorized token management functions.
Why it matters: Authentication, token design, endpoints, webhooks, error handling, testing, and compliance require technical review.
A vertical software company may want merchant customers to access payments from inside its application. As a result, onboarding, account ownership, underwriting, settlement, reporting, platform economics, and support responsibilities become especially important.
Why it matters: Embedded payments and marketplace disbursements may require specialized payment programs, provider approval, and different contracts. A standard VMS referral agreement does not establish payment facilitator capability, split payments, submerchant onboarding, or marketplace payouts.
Before discussing a processor, gateway, or possible integration, a technology partner can document the merchant's current environment and required payment workflow. This reduces avoidable implementation surprises.
Identify the POS, ecommerce platform, or custom application, including current versions, modules, and processor restrictions.
Ask: Does the vendor allow third-party payment processing?
Document terminals, PIN pads, mobile readers, printers, and device connection requirements.
Ask: Are the exact hardware models supported and approved?
Determine required gateways, supported acquiring arrangements, credentials, and provider permissions.
Ask: Does the gateway support the required payment methods?
Identify required refunds, voids, authorizations, captures, tips, partial approvals, recurring billing, or card-on-file workflows.
Ask: Which features are mandatory versus preferred?
Document settlement batches, fees, transaction identifiers, deposit reporting, and reconciliation needs.
Ask: How does the business reconcile POS sales to deposits?
Identify systems affecting cardholder data and which parties manage the relevant security controls.
Ask: Who maintains credentials, access, token custody, and incident response?
A software company shouldn't have to develop an integration just to make an occasional merchant introduction. Conversely, a platform seeking embedded payments needs more than a standard referral agreement.
Your business introduces interested merchants. VMS discusses applicable payment solutions while the parties coordinate the agreed handoff.
Key requirements: Consent, eligibility, tracking, permitted compensation, and support expectations. No integration is assumed.
A dealer may supply, configure, or support approved hardware or software while merchants evaluate related payment options.
Key requirements: Authorized products, provisioning, compatibility, deployment, warranties, training, and defined service roles.
A developer or platform may explore a proposed payment workflow through eligible provider capabilities.
Key requirements: Feasibility, documentation, testing, development ownership, security, applicable certification, and separate commercial terms.
Credible referrals arise from a specific business need. For example, a retailer replacing a POS and a software developer adding online payments face very different implementation questions.
A restaurant replaces aging POS equipment. The dealer must confirm terminal support, tipping workflows, end-of-day batching, and payment compatibility before recommending an approach. An approved VMS introduction may support the review.
A software company manages estimates and invoices for contractors. Users begin requesting remote card payments. A referral model can be evaluated first, with integration feasibility considered separately.
An agency builds an online store for a retailer. Checkout, refunds, order states, supported gateway plugins, and failure notifications all require clear technical ownership.
An MSP supports a merchant's devices and network. When the customer asks about payment terminals, network access, remote support permissions, and troubleshooting boundaries become relevant.
A retailer likes its current inventory system but wants lower processing expenses. The reseller can introduce an authorized review without promising that every component can be retained.
A SaaS provider wants recurring customer payments. Technical discovery should address billing, tokens, retries, failed-payment notices, refunds, and actual provider capabilities.
Payment environments span multiple technology and service layers. When something fails, the merchant wants a resolution, not a disagreement over which vendor owns the problem.
Therefore, an appropriate relationship should define escalation paths before deployment. The table shows where troubleshooting might begin.
| Merchant Issue | Area to Investigate | Potential Escalation |
|---|---|---|
| POS cannot send payment request | POS application, integration interface and local configuration | Software vendor or integrator, gateway or device provider as relevant |
| Terminal is offline | Power, networking, connectivity and device configuration | IT provider, terminal support or payment platform |
| Transaction declined | Response code, transaction state, issuer or processing response | Gateway, acquiring support or issuer as applicable |
| Approved sale missing from POS | Timeouts, response handling and transaction reconciliation | POS developer and payment gateway or processor |
| Bank deposit differs from sales | Batches, refunds, fees, reserves and cutoff timing | Processor, reporting provider and merchant accounting team |
| Recurring payment fails | Billing schedule, token status, response and retry rules | Billing software and relevant payment platform |
VMS provides or facilitates payment processing and related business solutions. Technology partners may encounter merchants who need new terminals, ecommerce checkout, mobile payments, or a processing expense review.
Available products, gateways, processors, hardware and integrations depend on eligibility, compatibility, provider approval, and commercial terms.
Consequently, POS referral partnerships should not promise that switching processors will preserve every software feature, stored token, settlement workflow, or device integration.
Security responsibilities differ depending on what each company actually does. For example, a hardware reseller and a developer operating payment APIs may have significantly different obligations.
Determine whether a software environment stores, processes, transmits, or could affect cardholder data security. Avoid collecting sensitive payment information through referral forms, ordinary emails, or uncontrolled logs.
A payment token may not work across processors or gateways. Token custody, migration rules, permissions, and customer authorization must be evaluated before promising continuity.
A company that sells equipment may have different security obligations from one that remotely manages payment systems or can access a merchant's cardholder data environment.
Outsourcing payment functions does not necessarily eliminate merchant security duties. The architecture, parties involved, and applicable validation rules still require review.
Start with the simplest appropriate commercial arrangement. Some partners need only an effective referral process. Others must validate technical requirements before an integration can be considered.
Discuss software, customer industries, current payment environment, and the reason for exploring a VMS relationship.
Determine whether a referral-only, reseller-related, or technical discovery model fits the need. Review eligibility and proposed terms.
Confirm compatibility, merchant consent, security, support, development scope, provider approvals, and applicable written agreements.
Make approved introductions or implement separately authorized technical work with clear responsibilities and reporting.
Founded in Idaho in 2006, Valued Merchant Services serves businesses nationwide with merchant processing, payment technology, and related solutions.
Led by co-founders Sean Ruppel, CEO, and Chris Del Grande, President, VMS emphasizes consultative service and long-term business relationships.
We recognize that a software company or POS dealer puts its customer relationship and reputation behind an introduction. For that reason, compatibility, technical scope, and support ownership deserve attention before commitments are made.
Explore the VMS Business Referral Partnerships program or read about Commercial Supplier & Distributor Referral Partnerships .
Illustrative image, not a photograph of an actual technology partner.
These answers cover integration feasibility, hardware compatibility, gateways, reseller relationships, merchant support, security, and referral compensation.
POS referral partnerships allow qualifying technology firms to introduce interested merchants to a payment services provider. VMS can discuss eligible solutions, while approved agreements define duties and compensation.
Potentially. A referral-only relationship may allow approved introductions without developing payment processing code. However, the merchant's existing technology still requires evaluation.
No universal compatibility is promised. Support depends on specific software versions, gateways, processors, hardware, configuration, and provider requirements.
Qualifying arrangements may include approved one-time compensation or ongoing revenue sharing. Eligibility, calculations, payments, and restrictions must be defined in writing. Earnings are not guaranteed.
A referral focuses on approved introductions. An integration project may additionally require development, testing, certification, security, implementation duties, and separate agreements.
VMS can discuss a proposed use case and whether technical discovery is appropriate. Supported APIs, testing environments, development assistance, and commercial terms must be verified.
Sometimes, but not automatically. Device models, encryption, software compatibility, certification, and contracts can affect hardware reuse.
A standalone device handles transactions separately from business software. An integrated setup coordinates activity through supported interfaces and applications. Reporting requirements may differ.
The appropriate design depends on the ecommerce platform, checkout needs, security architecture, gateway capabilities, maintenance responsibilities, and merchant requirements.
Specialized onboarding models may exist, but they are not assumed to be included in standard VMS referral arrangements. Provider, contractual, underwriting, and technical review would be required.
No. These capabilities are not promised on this page. Marketplace payments, submerchant onboarding, and payfac structures may require specialized programs and approvals.
Migration is not guaranteed. Portability depends on vault providers, token design, merchant permission, security requirements, and the source and destination payment platforms.
Support responsibilities must follow the relevant agreements. Software, terminal, gateway, processor, and network issues may involve different teams.
Responsibilities depend on actual activities. Equipment-only resellers may have different obligations from companies managing payment systems or accessing cardholder data environments.
No. Outsourcing may change which requirements apply, but it does not automatically eliminate a merchant's relevant responsibilities.
VMS considers eligible introductions from web and ecommerce developers. Relevant information includes platform capabilities, checkout needs, and compatibility constraints.
Potentially. MSPs may encounter payment needs while supporting business systems and devices. Customer permission and support boundaries must be respected.
Yes. An authorized processing statement review may be discussed separately from migration. Whether any subsequent changes preserve existing technology requires evaluation.
Relevant information may include platform names, versions, hardware, gateways, payment workflow, customer industry, and proposed relationship. Do not submit card numbers, passwords, API secrets, or sensitive credentials.
Complete the inquiry form below or call 208-243-0818. Describe your technology, customer types, and whether you seek a referral-only relationship or technical discovery. The initial discussion is nonbinding.
Whether you're a POS dealer, vertical SaaS provider, ecommerce developer, systems integrator, or managed IT services company, we'd welcome a discussion about the merchants you serve.
Tell us whether your goal is a straightforward merchant referral relationship or whether you have a specific workflow requiring technical discovery.
Form not displaying? Open the referral partnership inquiry directly.
An inquiry does not establish a partnership, authorize any integration, guarantee compatibility, confer certification, or guarantee compensation. Do not provide card data, API secrets, passwords, or sensitive production credentials through this form.
Valued Merchant Services provides or facilitates merchant processing and related business solutions subject to eligibility, underwriting, provider availability, approvals, and contractual terms. Payment architecture examples are educational and do not represent VMS-certified integrations. No universal POS, hardware, gateway, API, embedded-payment, marketplace, token-migration, split-payment, or payment-facilitator capability is promised. Software companies, merchants, resellers, and payment providers must evaluate actual PCI DSS and security duties based on their environment and contracts. Development, certification, equipment provisioning, underwriting, reporting, and support responsibilities require appropriate agreements. Referral compensation, where permitted, depends on an approved written agreement, qualifying activity, and applicable restrictions. Processing savings, compatibility, merchant approval, and referral earnings are not guaranteed. This page is informational and does not constitute legal, cybersecurity, compliance, or integration advice. Images are illustrative.