Provider evaluation
Listed, Eligible, Connected: What a Chargeback Provider Directory Entry Really Means
A provider directory entry tells you that a service has been described. It does not prove that your merchant account qualifies, that an integration is enabled or that current cases are synchronizing. Keep these states separate before you plan work around a new chargeback tool.
The useful buying question is not simply “Do you support this provider?” It is “Which part of the connection is available for our exact account, and what evidence shows it is working?” That wording turns a logo into an operational requirement.
Understand the four separate states
A listed service has a catalog profile. An eligible account meets the provider's applicable commercial and access requirements. A connected account has completed the necessary authorization through an available route. A verified synchronization has successfully retrieved the intended information from that account.
These are practical purchasing distinctions. Lower Chargeback's Provider Hub describes provider access paths and requirements. Its public product page also distinguishes catalog availability from activation of an eligible, registered connection.
Consider each state as a separate acceptance point. A merchant can be eligible for a product while the software adapter they hoped to use is unavailable. An adapter can exist while the merchant lacks the required provider agreement. Credentials can be accepted while the particular dispute feed remains unauthorized.
A single green “connected” label is therefore insufficient if nobody can explain what it confirms. It might mean only that authentication succeeded. Ask whether it also verifies the account identity, permitted product, relevant data and last successful update.
Ask for proof appropriate to each state
The proof should become more specific as the connection progresses.
| State | Evidence to retain | What it does not establish |
|---|---|---|
| Listed | Current product profile and access description | Your merchant's approval |
| Eligible | Provider confirmation for the entity and account | Working software access |
| Authorized | Account identity and approved permissions | Complete case visibility |
| Synchronizing | Sample records and recent successful refresh | Every optional action is supported |
Do not ask a seller to prove live data access before your account is authorized. Instead, agree on the sequence and on which commercial obligations begin at each point. This prevents a sales demonstration from being mistaken for a completed implementation.
The record should identify the source account, not merely the provider brand. A business might use the same provider across separate entities, acquiring relationships or regions. Approval for one does not automatically answer the access question for another.
Work through a hypothetical onboarding
Imagine a Shopify merchant using Shopify Payments for its store and a separate processor for another sales channel. The merchant sees both provider names in a catalog and assumes all disputes will immediately appear in one inbox.
The correct review separates the two sources. For Shopify Payments, the merchant checks the store authorization and supported monitoring data. For the external processor, it checks whether the relevant account already exists, which access method is available and whether the registered adapter is enabled for that relationship.
Suppose the external processor requires a provider agreement before production credentials can be issued. The catalog profile is useful because it reveals that dependency. It is not evidence that the software has bypassed the agreement.
The merchant's acceptance note should say: “Shopify source verified with sample cases. External processor listed; production access awaiting provider approval. External case monitoring remains in the processor portal until verification completes.” This is a clear operational state, not a failed promise disguised by a logo.
Define what successful synchronization means
Choose a small set of existing cases that can be checked in the authoritative source. Include an open case, a finalized case if available and a case with a deadline. Compare the provider account, case reference, amount, currency and status.
If there are no disputes, the verification should say so explicitly. An empty result can be valid, but it should follow a successful authorized request for the intended account. An authorization error must not be displayed as “no disputes.”
Ask how the product shows the last successful refresh and access failures. The merchant needs to distinguish an unchanged case from a case that has not been refreshed. These are user-facing acceptance requirements; the engineering methods used to achieve them can remain with the implementation team.
Also confirm historical coverage. Seeing new cases does not prove that older cases were imported. Decide which history is necessary for your immediate workflow and document any gap before retiring an existing view.
Purchase against a defined activation outcome
A suitable purchase record states which sources are required now, which are optional and what happens if one cannot be activated. It should identify the person responsible for provider approval, the person responsible for software configuration and the evidence needed to declare the connection ready.
Do not interpret successful read access as authority to refund, submit evidence or accept a network case. Those actions require their own supported workflow and authorization. A monitoring connection may be useful without any of them.
Finally, retain the native provider access needed to check urgent cases during onboarding. Once the agreed records have been verified, the team can adopt the new view with a precise understanding of its coverage. The directory has then done its job: it helped turn a possible service into an established, accountable connection.
Open Provider Hub to inspect each service's documented activation requirements.
Related reading in this collection:
- A Chargeback Software Demo Script That Tests Real Merchant Requirements
- American Express Raw Data Disputes: When Does Delegated File Access Fit?
- RDR Rules for Shopify Merchants: Define Authority Before Automation