What evidence should support a vendor's “UCP compatible” claim?
Ask a supplier claiming UCP compatibility to name the role, version, capabilities and environment it supports. Those details determine whether the integration fits the operation you want to perform.
Ask the vendor to finish the compatibility sentence
“UCP compatible” can refer to several different scopes. A supplier may expose a business profile, implement one capability, provide a client library or support a complete flow through another participant. These are not interchangeable purchasing claims.
Ask for a sentence that identifies the role, supported operation, version and environment. A fictional but useful form would be: “This demonstration implements the named operation in our sandbox using the stated release and listed dependencies.” The supplier must provide the real values; do not complete the sentence on its behalf.
| Evidence supplied | What you can reasonably inspect next |
|---|---|
| Profile URL | Declared capabilities, version and relevant endpoints |
| Library or connector | The operations it implements and what remains your responsibility |
| Sandbox demonstration | Inputs, observed states and failure handling in that environment |
| Production offer | Eligibility, access conditions and documented supported scope |
| Future roadmap | Planned work, kept separate from available functions |
UCP's core concepts provide the role vocabulary. A logo or an undated sales slide does not identify which of those roles the supplier actually performs.
Turn a demonstration into an acceptance record
Choose one operation relevant to your project and define the expected result. Ask the supplier to identify the participants and dependencies, then demonstrate the successful path and a relevant exception in an authorised test environment.
The record should show what was supplied, what was observed and what remains outside the demonstration. If the supplier uses a mocked payment step, preserve that fact. A mock can help review the interface while leaving payment interoperability untested.
A screenshot of a green status is insufficient when the commercial decision depends on recovery after interruption. Ask how the result is determined, how an operator sees uncertainty and who investigates an unresolved case. Those questions concern the service you will operate, not just the protocol vocabulary.
Separate protocol maintenance from service maintenance
A supported protocol release does not tell you how the vendor upgrades its service or communicates breaking changes. Request the applicable maintenance policy, the references used for the current implementation and the process for retesting your integration.
The UCP versioning policy describes the protocol's release and backport process. The vendor still needs to explain its own supported versions and dependencies. Keep both references in the acceptance record so a later incident can be tied to the actual configuration.
Finally, connect the evidence to a bounded decision. You may have enough information for a sandbox pilot and still lack the conditions for a production rollout. Writing those two decisions separately prevents an exploratory approval from being reused as if it authorised every capability or environment.
Ask what the supplier actually implements
Start with the participant's role and the operations it performs. UCP's core concepts provide the protocol vocabulary. Compare that description with the supplier's published UCP profile where applicable. Ask it to explain any difference between the profile, the proposal and the demonstrated behaviour.
A demonstration should identify the participant on each side. If a partner performs part of the flow, record that dependency and who is responsible when it fails.
Request separate evidence for commercial claims
Compatibility evidence does not establish higher conversion, lower support costs or guaranteed placement in an agent interface. Those claims require their own measurements and appropriate comparison conditions.
The Verity Score UCP reference is useful background for merchants comparing terminology. It is an editorial resource, not evidence that a particular supplier has passed your acceptance process.
If the supplier offers an audit or score, ask what inputs it examines and which behaviours it cannot observe. A content check and an end-to-end transaction test address different questions.
Put unresolved conditions in the pilot decision
A useful review concludes with one of several bounded outcomes: adequate evidence for the stated pilot, further evidence required, or unsuitable scope for the intended use.
Attach the unresolved conditions to the pilot acceptance criteria, with an owner for each missing proof. Approve the scope demonstrated by the evidence and leave untested capabilities outside that decision.
