Status is checked when this page loads. Refresh for a new check. These are published reference summaries; AI also requires an imported database record and a matching question. Approval and review dates do not mean AI is activated.
REVIEWED REFERENCEVisa: interchange and merchant pricing
Visa describes interchange as transfers between acquiring and issuing banks. A merchant negotiates a separate merchant discount with its financial institution; that price can include processing services. Distinguish network interchange from the full merchant processing price when discussing a statement. This reference does not establish an individual merchant's rates, processor markup, or savings.
Reviewed 2026-10-09 · Review due 2026-11-08
Read the original source ↗REVIEWED REFERENCEPCI SSC: responsibilities when outsourcing processing
Outsourcing payment processing does not eliminate a merchant's responsibility for protecting payment data. The merchant must assess the provider's compliance, document responsibilities, monitor compliance status, and clarify shared duties. Some technical requirements may not apply directly to the merchant environment. Confirm validation obligations with the acquirer or other organization managing the merchant's compliance program. This summary is educational, not a determination of an individual merchant's compliance.
Reviewed 2026-10-09 · Review due 2026-11-08
Read the original source ↗REVIEWED REFERENCEMastercard: interchange qualification and merchant pricing
Mastercard describes interchange as one component of the merchant discount rate set by an acquirer. Qualifying for a particular interchange category depends on multiple requirements, including merchant category, authorization-to-clearing timing and submitted transaction data. A quoted interchange rate is not the full merchant price. Check current network criteria and the merchant's acquirer agreement rather than assuming every transaction receives one rate. This reference contains no current numeric rate schedule.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEPCI SSC: card verification codes and storage
PCI SSC classifies card verification codes such as CVV2, CVC2 and CID as sensitive authentication data. They may be collected when necessary for authorization in a card-not-present transaction, but must not be retained after authorization, even in encrypted form. Merchant systems and procedures should prevent that retention. This reference does not determine a merchant's overall PCI compliance.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEFDIC: payment processor due diligence and underwriting
The FDIC's guidance on third-party payment processor relationships, amended in February 2026, describes due diligence, underwriting and ongoing monitoring by FDIC-supervised institutions. Topics include understanding merchant business lines and volume, reviewing a processor's onboarding practices and monitoring unauthorized returns, chargebacks and complaints. This is guidance for supervised financial institutions, not an approval checklist or guarantee for an individual merchant. Agents should ask their acquiring partner what documentation and review it requires.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEVisa: dispute prevention and merchant response
Visa describes a dispute as a reversal of all or part of a transaction's value through the issuer, acquirer and usually the merchant bank. Merchants should respond promptly when contacted by their acquirer and ask the acquirer or processor about applicable rules. Clear refund and cancellation policies, avoiding duplicate processing and keeping customers informed about delivery can help reduce avoidable disputes. Distinguish reversed transaction principal from any separate chargeback administration fee on a statement. This reference does not promise a successful dispute outcome.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEPCI SSC: POS terminal configuration and security
PCI SSC explains that payment terminals process account data and belong within the merchant's cardholder data environment. Applicable controls depend on the terminal's functions, connections and configuration; a complex POS system differs from a locked-down device. Review vendor configuration documentation and ask the organization managing the merchant's compliance program about device requirements. Buying a terminal alone does not establish the merchant's compliance or suitability for every integration.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEPCI SSC: point-to-point encryption and listed solutions
PCI SSC describes P2PE as protecting account data through encryption from capture at the payment device until decryption in the provider's protected environment. PCI-listed P2PE solutions can reduce the number of applicable PCI DSS requirements. The Council publishes solution, component and application listings for selection. This does not mean that every product advertised as encrypted is a listed P2PE solution, or that the merchant has no remaining responsibilities.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEPCI SSC: mobile contactless payments and MPoC
PCI MPoC addresses payment acceptance solutions using ordinary commercial mobile devices, including supported combinations of contactless card data and PIN entry. PCI SSC describes a modular security program and publishes evaluated solution listings. For a mobile or tap-to-phone discussion, identify the actual listed solution with the merchant's acquirer. The standard's existence does not mean that any phone, app or operating-system version automatically supports the intended payment workflow.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEVisa: payment facilitators and sponsored merchants
Visa's payment facilitator overview distinguishes the acquirer, payment facilitator and sponsored merchant. Under its model and the acquirer's arrangements, a facilitator can contract with sponsored merchants and distribute settlement proceeds on their behalf. Visa states that sponsored merchants remain subject to merchant requirements and that the acquirer is responsible for facilitator and sponsored-merchant activity. This overview does not establish an agent's residual split, contractual rights or eligibility to act as a facilitator.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: payment gateways and merchant accounts
Authorize.net explains the gateway's role connecting a merchant's payment channels with the organizations processing transactions, and distinguishes it from the merchant account held with the acquiring institution. Its gateway selection questions include supported payment methods, recurring payments and fraud tools. Use those as discovery topics for the merchant's checkout workflow. This provider-specific introduction does not prove compatibility with a particular POS or guarantee approval, funding timing or pricing.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: support responsibilities for funding and gateway issues
Authorize.net's support guide directs merchant-account deposits, processing fees, limits and statement questions to the merchant service provider, while gateway configuration questions belong with Authorize.net. A reseller may also be the merchant service provider or help identify the appropriate contact. When supporting an existing merchant, first identify the organizations responsible for the reported issue. These are Authorize.net's described support roles, not a universal support contract or a promised resolution time.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: webhook integration and transaction status
Authorize.net webhooks notify an integration about transaction, customer-profile and subscription events. Its documentation recommends using reporting APIs for additional details or current transaction status. Notifications include an HMAC-SHA512 signature based on the body and merchant Signature Key; the receiver validates it and rejects mismatches. Delivery can be retried. Agents should involve the integration developer to confirm event verification and reporting behavior rather than treating a browser redirect as proof of payment.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: hosted checkout forms and integration choices
Authorize.net Accept Hosted offers a provider-hosted payment form that can be embedded or reached through a redirect. An API request obtains a form token carrying transaction and display settings. The documentation describes different response behavior for embedded forms and redirects; a redirect back to the merchant site does not supply full transaction details. This is one provider's integration pattern, not a determination that the merchant's complete website meets PCI requirements.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: recurring subscriptions and payment outcomes
Authorize.net Automated Recurring Billing creates scheduled subscription payments. Successfully creating a subscription does not mean a payment has been authorized or will succeed; scheduled transactions and their results must be monitored separately. The provider documents failed-payment notices, subscription status, reporting APIs and subscription webhooks. For recurring-business discovery, ask how failed payments and cancellations are handled. This description does not establish customer consent, cancellation-law obligations or guaranteed recurring revenue.
Reviewed 2026-10-10 · Review due 2026-11-09
Read the original source ↗REVIEWED REFERENCEAuthorize.net: reseller residuals and contract termination example
Authorize.net's publicly posted North America reseller agreement, last revised May 2022, illustrates provider-specific residual conditions in sections 6 and 7. It ties residual payments to a sell rate above the buy rate and collection of merchant fees, and describes circumstances when payments stop. On termination, the agreement ends the right to earn future residuals while addressing amounts already owed. This is a gateway reseller contract example, not a universal ISO residual split, lifetime-income promise or interpretation of an agent's signed agreement. Review the actual applicable agreement and amendments with the provider and qualified counsel before relying on contractual rights.
Reviewed 2026-10-11 · Review due 2026-11-10
Read the original source ↗REVIEWED REFERENCEOCC: risk-based merchant underwriting and delayed delivery
The OCC's Merchant Processing handbook (August 2014, amended March 2025) describes bank-facing underwriting and review on printed pages 22–25. Review depth should reflect merchant risk; topics include business validity, creditworthiness, sales history and processing activity. Higher-risk merchants may receive more extensive analysis and monitoring. Future or delayed delivery can increase chargeback exposure; the handbook discusses reserves as a bank risk-management tool. This educational bank-supervision reference does not set universal high-risk merchant approval criteria, reserve percentages or funding schedules. Ask the acquiring partner which current documentation and review its program requires; approval cannot be promised.
Reviewed 2026-10-11 · Review due 2026-11-10
Read the original source ↗REVIEWED REFERENCESBA: customer retention and post-sale follow-up
A May 2016 guest article published by SBA recommends post-sale contact to learn how a customer is using a service, answer questions and address problems. It also suggests inviting customer feedback during service development. Agents can adapt those general practices into merchant retention conversations: ask what is working, identify unresolved support needs and agree on follow-up. That application is ISOHub's interpretation, not an SBA payment-processing program. The article does not establish a required contact schedule, guaranteed retention improvement or permission to send marketing messages.
Reviewed 2026-10-11 · Review due 2026-11-10
Read the original source ↗REVIEWED REFERENCEStripe: Terminal integration, smart readers and offline limits
Stripe's server-driven Terminal integration connects a POS application and backend to supported smart readers through the Stripe API, with webhooks reporting payment status. This particular integration mode does not support Stripe mobile readers or collecting card payments offline. For discovery, ask about the merchant's POS software, reader model, backend integration and internet availability before proposing a setup. These are Stripe-specific implementation limits, not a statement that every Terminal integration lacks offline support or that an existing POS is automatically compatible.
Reviewed 2026-10-11 · Review due 2026-11-10
Read the original source ↗REVIEWED REFERENCESquare: POS catalog migration and item-import checks
Square documents spreadsheet-based item catalog imports and updates. Before changing an existing catalog, it recommends keeping a separate exported backup. Its instructions cover column mapping, location-specific fields and protecting SKU formatting from spreadsheet conversions. In a POS migration conversation, identify what catalog data must move and who will check the import. This article concerns Square's item library; it does not establish transfer of transaction history, stored payment credentials or all features from another POS, or guarantee a migration without downtime.
Reviewed 2026-10-11 · Review due 2026-11-10
Read the original source ↗