Explain It in 30 Seconds
A bank wants to issue a card.
Connecting the card to a network is only part of the job.
The institution also needs systems to handle account-related transaction activity, manage exceptions and support customers after launch.
DPS supplies processing and services around that continuing operation.
The issuer can obtain infrastructure from a specialist without selling its deposit or lending relationships to the processor.
The financial product and the technology operating it remain different parts of the system.
Where It Sits in Visa
Within Visa, DPS serves the issuing side.
VisaNet connects institutions through shared network infrastructure. Merchant services support acceptance. DPS handles contracted processing and operations for an issuer's program.
The institution can therefore make separate decisions about its network, processor and internally operated functions.
The Problem It Solved
A card program needs continuing operation after its first card is issued.
Payments arrive, customers change accounts and disputed or interrupted transactions need attention. Records and product rules must remain consistent.
A processor makes parts of that infrastructure reusable across institutions, reducing what each must build itself. The issuer still needs oversight and responsibility for its customer relationship.
How It Works — Simple Version
A simplified issuer-processing arrangement connects several activities.
1. The institution establishes the account and card program. 2. Processing systems support the configured program and its transaction activity. 3. Payment requests and outcomes connect with the issuing side. 4. Financial records and reporting support reconciliation. 5. Fraud, disputes and servicing functions handle the continuing lifecycle.
The exact configuration depends on the contract and program.
DPS's public portfolio includes processing, digital issuance and operational services. The client does not necessarily buy every capability. [S1][S49]
The useful unit is a working issuer program, not simply another API endpoint.
Major Service Families
Processing
Transaction activity must be handled consistently with the configured account and program.
A quick response is useful only if the underlying treatment is correct.
Digital issuance and access
DPS describes digital-card and wallet-enablement capabilities.
These connect the customer's interface with the institution's issuing operation. [S49]
Fraud and dispute operations
An issuer needs to assess suspicious activity and handle later questions about transactions.
Those are different jobs from the original network connection.
Analytics and supporting services
Visa's disclosed DPS scope includes services such as analytics, campaign management and contact-center support. [S1]
These extend the relationship around operating the program.
Their availability does not mean every client uses the same service bundle or outsources all customer contact.
The Issuer-Processing Stack
| Layer | Main role |
|---|---|
| Institution | Provides the account, product and customer relationship |
| Program configuration | Defines supported operating behavior |
| Processor | Handles contracted transaction and account-service functions |
| Payment network | Connects participating institutions for supported payments |
| Servicing | Handles inquiries, changes and exceptions |
| Reporting | Helps the institution reconcile and oversee activity |
One supplier can occupy several layers. Keeping them distinct helps an institution locate a problem: account treatment, processing, connectivity and servicing require different responses.
A New Feature Still Needs the Program Behind It
Flexible Credential connects customer choice with issuer processing.
An eligible funding-source selection in an app must produce the correct transaction treatment and account record. Processing, account mapping and customer support need to agree about what the selection means.
DPS presents the capability as API-enabled for issuer frameworks, not as a feature already implemented by every existing program. [S48]
Who Uses It?
Issuing institutions
They buy defined processing and operating capabilities.
Their decision depends on program requirements, existing systems and what they want to operate themselves.
Issuer technology teams
They connect the processor with the institution's systems and customer channels.
Operations teams
They reconcile activity and manage changes or exceptions.
Customer-service teams
They need information and permitted actions that fit the issuer's product.
The cardholder uses the resulting financial service.
That customer need not have a separate direct relationship with DPS.
Multi-Network Is Not the Absence of Network Rules
Multi-network processing lets an issuer support more than one payment brand through a processing relationship.
Network, program and market requirements still differ. Visa's ownership does not transfer ownership of the client's competing brands or establish that every feature works on every route.
The institution needs the actual contracted program scope.
How the Economics Work
The institution pays for contracted processing and services, not for ownership of its account balances.
Its comparison needs integration, support and change-management costs as well as message-processing prices.
The DPS API overview states that charges depend on contractual arrangements and that issuers remain accountable for their vendors' API usage. A testable interface is therefore not necessarily free or unrestricted in production. [S93]
Scale
DPS's public processing page reports 52 billion annual authorizations for fiscal 2024. [S49]
That is a dated authorization measure.
It is not a current count of customers, all Visa transactions or separately disclosed DPS revenue.
A large processing base can support reusable infrastructure. It also makes reliability and controlled change important because interruptions can affect many customer programs.
What It Depends On
Institutional configuration
The processor needs an accurate understanding of the supported account and product.
Integration
The issuing institution's systems and digital channels must work with the contracted functions.
Production eligibility
The public Card and Account Services APIs describe debit and prepaid scope.
Production access is limited to DPS issuers and partners, and back-end integration may be required. Sandbox access does not establish production authorization. [S93]
Servicing and controls
The institution needs workable procedures when transactions are disputed, credentials change or customers ask questions.
Reliability
A reusable processor becomes part of the issuer's operating dependency.
The relevant confidence concerns the actual service and agreement, not an unqualified promise that every component is always available.
What Depends on Visa DPS
Clients can build supported issuing programs around DPS processing, reporting and servicing.
Their customer interfaces and operations may then depend on those contracted functions. They retain the account products and need a clear division of work with the processor.
DPS and Pismo
Visa completed the Pismo acquisition in January 2024, adding cloud-native processing and core-banking technology. [S12]
That expands the issuer-services portfolio but does not establish that DPS programs automatically migrated to Pismo.
The platforms have distinct histories and implementations. A client still needs to identify the product and operating arrangement it is buying.
Why It Matters to Visa
DPS gives Visa a role in institutions' continuing payment operations, beyond network connectivity.
Multi-network programs widen that role without requiring Visa to own the bank's accounts or brand every underlying payment. The value is dependable operating capability for the issuer.
Before / After
Operating every function independently
The institution must build or assemble its program's processing, integration and support.
Using contracted DPS capabilities
It can reuse specialist infrastructure and services while retaining its account products and oversight.
The changed constraint is how much operating capability it must maintain itself.
What Most People Misunderstand
“DPS is the same as VisaNet.”
Issuer processing and a shared payment network serve different roles.
“DPS owns the cardholder's account.”
The issuing institution retains the underlying relationship.
“Multi-network means every feature works everywhere.”
Actual support depends on the program, route and market.
“Anyone testing the API can operate a live issuer program.”
Production access and integration are separate requirements. [S93]
“The Pismo acquisition automatically replaced DPS.”
The transaction does not establish an automatic migration of every client program.
Key Milestones
January 2024 — Pismo joins the wider portfolio
Visa added another processing and banking-software platform, with a distinct product history. [S12]
Fiscal 2024 — Reported processing scale
The public DPS material identifies its annual authorization measure for that fiscal year, not a timeless current count. [S49]
Current API access model
Card and Account Services remain described as functions for eligible DPS issuers and partners in production. [S93]
Evidence
- [S1] Multi-network issuer-processing role and disclosed service families.
- [S49] Current product description and dated fiscal-2024 scale.
- [S93] Specific API scope, eligibility and contractual-use boundaries.
- [S48] A feature-integration example.
- [S12] The separate Pismo acquisition.
The stack and issuer-program examples explain the division of work; they do not disclose a private client architecture or certify a production deployment.