Things to Know

Before you begin integrating with the Visa Accept Service B2B APIs, it is important to understand the underlying logic and key structural concepts. Understanding the seller lifecycle and workflow dependencies helps prevent integration errors and helps ensure successful seller onboarding and transaction processing.

Resource Hierarchy

Understanding how data is structured helps prevent integration errors.

Resource	Role	Dependencies
Application	Parent	Foundation configuration that determines integration mode and account policies for all operations
Seller	Primary	Must be enrolled and ACTIVE before transaction processing; requires valid card eligibility and name tag availability
Device	Child	Depends on existing seller account; only required for Hybrid mode integrations with cryptographic keys
Transaction	Child	Requires active seller status; refund transactions require original transaction ID reference
Compliance Data	Child	Submitted after seller enrollment completion for KYB/Terms and Conditions requirements where applicable

Core Business Rules

Seller Lifecycle Management: Transactions can only be attempted after sellers are fully onboarded and activated. The seller must have ACTIVE status before any payment processing begins.
Sequential Workflow Requirements: You must complete seller onboarding and activation before transaction processing begins. Transaction processing workflows depend on an active seller profile, and refund workflows depend on previously processed transactions with valid transaction references.
Client System Responsibility: You are responsible for designing your own user interfaces and user experiences and for invoking the Visa Accept APIs from your backend systems as required by your chosen workflows. The APIs do not impose specific UI or system design requirements beyond standard API consumption and workflow handling.
Reference Management: You must retain original transaction identifiers required for refunds or reconciliation. Refund transactions require valid references to completed purchase transactions.
Production Readiness: You must complete all prerequisites and validations before production go-live. Incomplete or inconsistent configuration across systems will prevent successful integration.

Guardrails and Limitations

Rate Limits: There are no specific call-frequency, batching, or transaction-per-second requirements prescribed for clients consuming the Visa Accept Service B2B APIs. Clients with specific volume or performance requirements should review those expectations with the Visa Accept team as part of onboarding.
Regional Availability: The APIs can be consumed only in regions where Visa Accept is available. Once available in a given geography, API behavior may vary based on local regulatory requirements or participant models.
Production Scale Design: The APIs are designed to support multiple clients and production-scale usage within standard Visa platform controls. Standard VDP rate limiting likely applies though not explicitly documented in the API specification.
Data Retention: Transaction history supports pagination for large datasets with timestamp-based filtering. Specific data retention periods should be confirmed during implementation planning.
Market-Specific Requirements: Clients should confirm regional availability and validate any market-specific requirements as part of implementation. Local regulatory requirements or participant models may affect API behavior.