Merchant acceptance
Define card and account-to-account acceptance requirements across in-person, online and authorised remote channels, then assess an appropriate provider and acquirer route.
The options described on this page are subject to merchant eligibility, underwriting, provider and acquirer approval, technical compatibility and applicable agreements. They are not commitments that every method, device or feature is available.
Merchant acceptance
Map checkout, account-payment and support requirements before assessing a provider and acquirer route.
Card-present and card-not-present needs are scoped to the approved merchant model.
ACH, gateway, virtual-terminal and equipment needs remain subject to confirmation.
Relevant parties assess underwriting, compatibility, pricing and operating terms.
Transaction, refund, dispute and cost records return to merchant operations and finance.
Acceptance model
A useful merchant-services brief explains how customers pay, where transactions begin and which party owns each operational step. Product selection follows that map.
Acceptance capabilities
Each capability begins as a requirement to assess. The approved provider documentation and merchant agreement determine the final functionality, pricing and operating obligations.
Card-present and card-not-present requirements can be scoped around the merchant journey, transaction profile and approved sales channels.
Where available and appropriate, bank-account payment workflows such as ACH can be assessed alongside card acceptance.
Gateway requirements should begin with the website, platform or software environment and the customer journey it needs to support.
An approved virtual terminal may support authorised staff taking remote payments without a customer-facing online checkout.
Countertop, mobile or integrated equipment requirements can be matched against an approved provider catalogue and deployment plan.
A cash discount concept requires a transparent pricing and customer-communication design, not simply a change to terminal settings.
Transparent cost review
A useful review starts with recent processing information, contractual fees and operating needs. Its purpose is to make the present cost structure and proposal assumptions visible, not to promise a saving.
Review recent processing statements, pricing schedules, gateway and equipment charges, dispute fees and material contract terms through an agreed secure channel.
Add transaction channels, volume and ticket ranges, refund and dispute patterns, integration needs and support responsibilities so figures are not compared in isolation.
Separate fixed, variable, pass-through, equipment and service costs, then document which assumptions or exclusions could change the comparison.
A cost review is informational and is not an offer, approval or guarantee of savings. Future costs depend on underwriting, transaction mix, provider and acquirer pricing, network assessments, hardware, optional services, taxes and the final merchant agreement.
Merchant-services path
Acceptance design should make business, technical and commercial dependencies visible before a merchant commits to a route.
Document the business, customers, sales channels, transaction profile, refunds, disputes and current technology.
OutputAcceptance requirementsIdentify checkout, gateway, equipment, finance and support dependencies, including who owns each operating step.
OutputOperating modelAssess eligibility, underwriting information, technical compatibility and proposed commercial terms with relevant providers.
OutputDocumented scope decisionIf approved and accepted, agree configuration, testing, training, migration, support and launch responsibilities.
OutputImplementation planProgramme outcomes
The work should leave the merchant with reviewable requirements and terms rather than a list of untested product claims.
In-person, online, remote and account-to-account needs are documented with their operating dependencies.
The roles of the merchant and relevant technology, service and acquiring parties are made explicit.
Implementation begins only after eligibility, scope, compatibility, pricing and applicable terms are agreed.
Common questions
This website does not state that Rebate Card Exchange is an acquirer, processor or payment institution. The entities responsible for processing, acquiring and any regulated services are identified in the applicable proposal and merchant agreements.
Existing technology can be included in discovery. Compatibility, certification, provider support and any required change must be confirmed before implementation.
No universal conclusion should be assumed. The proposed design requires review under applicable law, network rules, provider and acquirer requirements, and the merchant should obtain appropriate advice before launch.
Pricing depends on the business, transaction profile, acceptance methods, underwriting, equipment, provider and acquirer terms. Only a written proposal and final merchant agreement establish the applicable cost.
Merchant discovery
Tell us how customers pay today, what needs to change and which systems are involved. Do not send statements or sensitive payment data through the public enquiry form.
Discuss merchant acceptance