Visa Commercial Payment Controls (VPC)
Product Overview
Visa Commercial Payment Controls lets clients set controls on commercial card accounts to protect commercial payments and limit spending at the card level. Clients register existing card accounts and then apply dynamic, near real-time rules (for example: spending, merchant category, location, channel, and business hours), so authorization decisions align to business use cases.
The primary audience includes Fintechs, issuers, or processors who can use these services on behalf of an issuer and their portfolio, for B2B payments ranging from Commercial to Small Business card portfolios. The service can be used with physical plastic cards or virtual cards and is supported for contactless transactions.
VPC API List
Account Management Service
Use the Account Management Service to create accounts within the ranges specified during the onboarding of an issuer or commercial client. This service also lets you add payment controls, manage account contacts, update company information, delete accounts, and retrieve account details.
- Create Account
- Get Account
- Update Account
- Delete Account
Rules Management Service
After registering a card with VPC, you can use the Rules Management Service to manage payment controls for that card. The service includes operations to set, delete, retrieve, block, disable, and enable rules. These operations let you configure controls, review existing rule configurations, block an account, and temporarily disable or re-enable rules as needed.
- Set Rules
- Get Rules
- Delete Rules
- Block Account
- Disable Enable Rules
Reporting Management Service
The Reporting Management Service lets you retrieve transaction and notification details for a card.
- Get Notification History
- Set Notification History
Intelligent Payment Controls
The Intelligent Payment Controls (IPC) system uses generative AI to evaluate user prompts and recommend the most appropriate controls for commercial card transactions. Based on the provided input, IPC suggests a tailored set of controls that can be reviewed and confirmed before being applied.
- Get Suggested Rules
- Set Suggested Rules
Notification Service
The Notification Service lets issuers, fintechs, and users choose whether to receive optional email or SMS alerts when VPC blocks or approves a transaction authorization request. Notifications are sent to the contacts specified when the card account is created through the Account Management Service.
This service must be enabled during issuer and fintech onboarding to Visa Commercial Payment Controls (VPC).
VPC Getting Started
This page provides information needed to begin integrating with Visa Commercial Payment Controls (VPC). Review the prerequisites, configure authentication and environment settings, and make your first API call.
Prerequisites
Before you begin using Visa Commercial Payment Controls APIs, complete the standard VDP setup requirements:
- Review the Visa Developer Quick Start Guide for account setup and API credential configuration
- Obtain your API credentials (User ID, Password, Certificate) from the Visa Developer Portal
- Configure your development environment for API integration
Additionally, ensure you meet the product-specific eligibility requirements:
- Issuer Authorization: Participation must be done on behalf of an issuer and their portfolio
- Third-Party Agent Setup: If you are not the issuer directly, the issuer must grant authorization for your entity to act as an agent for the issuer
- Contracting Requirements: A Visa Representative will discuss contracting requirements during implementation
- Production Authorization: An issuer will be required prior to moving to production, and all API calls will be made on behalf of an issuer acting as a third-party agent
Technical prerequisites include:
- Issuer and Third-Party Configuration: Issuer and third-party agent (Fintech) should be onboarded and configured through VCS Hub
- Account Number Ranges: Account number ranges must be pre-configured during VPC implementation
- VisaNet Processing: Transactions must flow through VisaNet for authorization controls to be applied
Environment Hosts & URL Recipe
Sandbox Environment:
Base URL: https://sandbox.api.visa.comProduction Environment:
Base URL: https://api.visa.comURL Construction Pattern:
{baseURL}/vpc/v1/{resource-path}Example URLs:
- Account Management: /vpc/v1/account/create
- Rules Management: /vpc/v1/rules/set
- Report Management: /vpc/v1/report/get-transaction-history
- Intelligent Payment Controls: /vpc/v1/vpcgenai/get
Headers and Authentication
Visa Commercial Payment Controls uses Two-Way SSL (mutual authentication) with Message Level Encryption due to the sensitive nature of account information being sent.
Required Headers:
- Content-Type: application/json
- Accept: application/json
- Authorization: Basic {base64-encoded-credentials}
For detailed authentication setup, including Message Level Encryption configuration for account information protection, see the Authentication Methods section.
First API Call
Test your integration by creating an account in the system. This is typically the first step in setting up payment controls for a card.
Endpoint: POST /vpc/v1/account/create
Sample Request:
{
"isToken": false,
"lastName": "Smith",
"firstName": "John",
"isBlock": false,
"customerCompanyId": "Visa_123",
"issuerBid": "99999999",
"companyName": "Visa",
"accountNumber": "4000123456789010",
"contacts: [
+ { ... },
+ { ... }
],
"customerClientId": "customerClientId"
}Expected Response Codes:
- 200 OK: Successfully created Account
- 400 Bad Request: An invalid account number has been entered
Next Steps:
After successful account creation, proceed to configure initial payment control rules using the Rules Management APIs. Use the Report Management APIs to monitor transaction authorization decisions and rule effectiveness.
VPC Things to Know
Essential business rules, technical constraints, and integration considerations for successful payment control implementation on commercial card accounts.
Introduction
Understanding the underlying business logic and technical requirements of Visa Commercial Payment Controls is critical for successful integration. This solution enables dynamic, near real-time rule application for commercial card accounts, requiring careful attention to rule management patterns, authorization flow dependencies, and VisaNet processing requirements.
Resource Hierarchy
This table shows the key resources and their dependencies in the Visa Commercial Payment Controls system:
| Resource | Role | Dependency |
|---|---|---|
| Account | Card Registration Entity | Must exist before rule setting |
| Contact | Notification Recipient | Optional; specified during account creation |
| Rules | Payment Control Logic | Requires account registration (except Block Rules) |
| Transaction Authorization | Business Outcome | Requires VisaNet processing and active rules |
Core Business Rules
Follow these core business rules to prevent integration failures:
- VisaNet Processing Requirement: For the service to work, transactions must flow through VisaNet for authorization; authorization controls can only be applied to transactions on Visa branded cards that are processed through VisaNet
- On-Us Transaction Handling: For On-Us transactions or domestic processing scenarios, issuers/processors need to integrate through Visa Transaction Exchange (VTEX) and make a call out to VisaNet to apply the controls during authorization processing
- Issuer Authorization Requirement: Participation must be done on behalf of an issuer and their portfolio, with proper authorization for third-party agents
- Account Registration Precedence: Registering cards (Create Account) is required before setting any rules other than the Block Rule
- Rule Activation Immediacy: Rules are active immediately upon setting and apply to subsequent authorization requests
- Full Refresh Pattern: Set Rules API requires sending all rules to be applied in a single request (full refresh)
- Case-Insensitive Request Fields: API request fields are case-insensitive. All required fields must be present, but field order is flexible.
- Timezone Handling: GMT is used by default for time-based rules. A timezone override is available — specify a supported timezone when configuring channel and time-based rules. See Supported Time Zones for valid values.
Guardrails & Limitations
Understand these system constraints when designing your integration:
- Payload Size Limitations: Each account can have multiple rules if the payload doesn't exceed 30720 bytes maximum size. The Rules Management error codes include "Payload size exceeds maximum allowed size of 30720 bytes."
- Historical Data Constraints: Report Management APIs have a 90-day historical data limit for transaction and notification history retrieval.
- Sandbox Environment Limitations: The sandbox environment provides only static values and a limited subset of possible requests. Clients cannot execute all API functionality or see the full list of accurate error codes through the API explorer in sandbox.
- Multi-Party Participation Scope: Services can be used by multiple parties including fintechs, issuers, or processors; however, participation must be done on behalf of an issuer and their portfolio. Supports physical plastic cards, virtual cards, and contactless transactions for B2B payments ranging from Commercial to Small Business card portfolios.
Authentication and Security Considerations
Special authentication requirements apply to Payment Controls APIs:
- Two-Way SSL Requirement: Visa Developer secures connections with clients using Two-Way SSL (mutual authentication)
- Message-Level Encryption: Required for API usage due to the sensitive nature of account information being sent
- Credential Management: Credentials and certificates for both SSL and message-level encryption are provided within the Visa Developer account
Development and Testing Considerations
Important considerations for development and testing:
- API Specification Authority: Clients should code using the API specifications (including error codes) rather than mimicking the API explorer behavior in sandbox
- Production Environment Setup: Account ranges must be pre-configured during VPC implementation before production use
- Notification Templates: Notification templates require implementation setup and testing in production environment
- Real-time Processing: Production environment supports real-time transaction processing with immediate rule application
- Testing Limitations: Sandbox provides limited testing scenarios; comprehensive testing requires production-like data and configurations
Integration Patterns
Follow these proven integration patterns for optimal results:
- Sequential Setup Pattern: Follow the required sequence: Account > Rules > Monitoring > .
- State Management: Track account keys, and rule configurations for subsequent operations.
- Error Handling: Implement comprehensive error handling for rule validation and authorization decision processing.
- Notification Integration: Configure notification systems for payment control alerts and authorization decisions.
- Reporting Integration: Implement regular transaction and notification history analysis for rule optimization.
- AI-Assisted Enhancement: Leverage Intelligent Payment Controls for data-driven rule suggestions.
Success Indicators
Integration is successful when these outcomes are achieved:
- Account Registration: Successful registration of existing card accounts in the payment controls system
- Rule Application: Payment control rules are successfully configured and applied to authorization processing
- Real-world Authorization Control: Rules effectively influence authorization decisions for actual transactions
- Notification System: Proper delivery of payment control authorization notifications
- Business Outcome Achievement: Protection of commercial payments and effective spending limitation according to business use cases
Common Integration Pitfalls
Avoid these common challenges based on system design:
- Workflow Sequence Violations: Attempting to set non-Block rules before account registration
- Sandbox Over-Reliance: Depending solely on sandbox API explorer behavior instead of API specifications
- VisaNet Processing Assumptions: Not accounting for On-Us transaction scenarios requiring VTEX integration
- Payload Size Overruns: Exceeding 30720 bytes limit when configuring complex rule sets
- Full Refresh Misunderstanding: Not sending complete rule sets when using Set Rules API
- Authentication Setup Issues: Improper Two-Way SSL or message-level encryption configuration
- Expecting Individual Rule Deletion: The Delete Rules operation removes ALL rules for an account — individual rule removal is not available. Use Block Account as an alternative when all transaction processing must be stopped.
Additional struggle and integration mistake patterns will be documented as more client feedback becomes available.
How to Use VPC
Learn the primary workflows for implementing dynamic payment controls on B2B card portfolios through account registration and rule management.
Workflow Overview
Visa Commercial Payment Controls supports two primary categories of workflows: onboarding workflows for establishing card controls and ongoing management workflows for dynamic rule adjustments. The typical client journey begins with adding card account, progresses through initial rule configuration, and continues with ongoing rule management and transaction monitoring.
The complete workflow enables clients to protect commercial payments and limit spending at the card level through dynamic, near real-time rules that align authorization decisions with business use cases.
Onboarding Workflow
The onboarding workflow establishes the foundation for payment control operations:
1. Account Setup: Register existing card accounts. This step is required before setting any rules other than the Block Rule.
POST /vpc/v1/account/create2. Initial Rule Configuration: Configure initial payment control rules per business use case. Use Set Rules API which performs a full refresh requiring all rules to be applied in a single request.
POST /vpc/v1/rules/set3. Validation and Testing Verify account setup and rule implementation using GET operations to confirm configuration.
GET /vpc/v1/account/getGET /vpc/v1/rules/getOngoing Management Workflow
The ongoing management workflow handles dynamic rule adjustments and monitoring:
1. Account Information Management Manage card account information including updates to account details and contact information.
POST /vpc/v1/account/updateGET /vpc/v1/account/getTo permanently remove an account and all associated rules and notifications:
DELETE /vpc/v1/account/delete2. Dynamic Rule Management Manage payment controls in near real-time including spending rules, merchant category rules, location, channel, and business hours restrictions.
POST /vpc/v1/rules/setPOST /vpc/v1/rules/disable-enableDELETE /vpc/v1/rules/deleteDelete Rules removes all current and future rules for the account. Individual rule removal is not available. Use Block Account to prevent all transaction processing when rules have been cleared.
3. Transaction Monitoring: Use GET functionality to pull card/account details, retrieve existing rules and spend usage, and view decline/authorization data.
GET /vpc/v1/report/get-transaction-historyGET /vpc/v1/report/get-notification-history4. AI-Assisted Rule Generation: Use Intelligent Payment Controls to generate AI-suggested rules. Submit a usage description to Get Suggested Rules, which evaluates the prompt and returns recommended controls along with a Rule Set ID. Pass the Rule Set ID — with any optional modifications — to Set Suggested Rules to apply the controls. The card account must exist before using these APIs.
GET /vpc/v1/vpcgenai/getPOST /vpc/v1/vpcgenai/setSuggestedRulesPayment Control Rule Types
Implement different types of payment control rules based on business requirements:
- Spending Rules: Set transaction amount limits and spending velocity
controls to prevent excessive spending. Configure daily, weekly, or monthly
spending limits per card account.
Use Cases: Employee expense limits, vendor payment controls, departmental budget enforcement.
Currency specification is required for spending rules. All spending rules for a given account must use the same currency. See Supported Currencies for valid currency codes.
- Merchant Category Rules: Control which merchant categories are allowed or
blocked for specific card accounts. Use MCC (Merchant Category Code) based
restrictions.
Use Cases: Restricting entertainment expenses, limiting fuel purchases, controlling office supply vendors.
- Location-Based Rules: Implement geographic restrictions based on country,
region, or specific location parameters.
Use Cases: Domestic-only transactions, regional business restrictions, travel-specific controls.
- Channel and Time-Based Rules: Configure channel restrictions (online,
in-store, ATM) and business hours limitations for transaction approval.
Use Cases: Business hours enforcement, channel-specific restrictions, contactless payment controls.
GMT is used by default; a timezone override is available. See Supported Time Zones for valid timezone values.
Rule Management Best Practices
Follow these patterns for effective rule management:
- Full Refresh Pattern: The Set Rules API requires sending all rules to be applied in a single request, performing a full refresh of existing rules
- Rule Activation: Rules are active immediately upon setting and apply to subsequent authorization requests
- Payload Limitations: Each account can have multiple rules as long as the payload doesn't exceed 30720 bytes maximum size
- Block Rule Exception: Block rules can be set during account registration, while all other rules require account registration first
- Notification Integration: Configure notifications to monitor authorization decisions
Reporting and Monitoring Implementation
Implement comprehensive monitoring using reporting operations:
- Transaction History Analysis: Use transaction history reporting after authorizations/declines occur to evaluate rule effectiveness. Notification configuration is not required to use Get Transaction History.
- Notification History Tracking: Monitor notification delivery to ensure stakeholders receive timely alerts. Get Notification History requires prior notification configuration — contacts must be specified during account creation.
- Spend Usage Monitoring: Use Get Rules to retrieve all active controls with consumed spending amounts and authorization counts for specific rule types. Track spending patterns and rule triggers to optimize control configurations.
- Decline Analysis: Analyze authorization decline patterns to identify potential business impact
- Pagination Handling: Use pageNumber parameter and isLastDataSet field for comprehensive data retrieval
Integration Success Validation
Validate successful integration through these key indicators:
- Account Registration Success: Successfully register existing card accounts in the system
- Rule Configuration Success: Successfully set and retrieve payment control rules with immediate activation
- Real-world Authorization Control: Verify that rules are applied correctly during actual transaction authorization processes
- Notification Delivery: Confirm notification system delivers alerts for rule-based authorization decisions
- Reporting Functionality: Successfully retrieve transaction history and notification history
The ultimate success indicator is when payment control rules effectively protect commercial payments and limit spending according to business use cases, with proper monitoring and reporting capabilities in place.
VPC Authentication Methods
Enhanced security authentication using Two-Way SSL with Message Level Encryption for sensitive account information in Payment Controls operations.
Enhanced Authentication Overview
Visa Commercial Payment Controls requires enhanced authentication due to the sensitive nature of account information being sent. The solution implements Two-Way SSL (mutual authentication) combined with Message Level Encryption to provide maximum security for commercial card account data during payment control operations.
This enhanced authentication approach goes beyond standard VDP authentication patterns to ensure that sensitive commercial card portfolio information remains protected throughout all API interactions.
Credential Acquisition
Obtain the required credentials through the standard VDP eligibility process with additional Payment Controls requirements:
- Issuer Authorization: Confirm participation is done on behalf of an issuer and their portfolio
- Third-Party Agent Setup: If not the issuer directly, obtain issuer authorization for your entity to act as an agent
- Visa Representative Coordination: Work with Visa Representative during implementation to discuss contracting requirements
- VDP Account Setup: Obtain credentials and certificates for both SSL and message-level encryption from your Visa Developer Portal account
- Production Authorization: Ensure issuer authorization is completed before moving to production
Authentication Setup Instructions
Configure your system for Two-Way SSL with Message Level Encryption authentication:
Configure your HTTP client for Two-Way SSL (mutual authentication) using the SSL certificate provided in your Visa Developer Portal account. Ensure proper certificate chain validation and mutual authentication setup.
Implement Message Level Encryption for request payloads containing account information. Use the MLE certificate provided in your Visa Developer Portal account for payload encryption.
Identify which API operations require MLE encryption based on sensitive account data presence:
Maintain both SSL and MLE certificates with proper renewal procedures to prevent authentication disruptions.
Two-Way SSL Configuration
Configure your HTTP client for Two-Way SSL (mutual authentication) using the SSL certificate provided in your Visa Developer Portal account. Ensure proper certificate chain validation and mutual authentication setup.
Message Level Encryption Setup
Implement Message Level Encryption for request payloads containing account information. Use the MLE certificate provided in your Visa Developer Portal account for payload encryption.
Account Information Identification
Identify which API operations require MLE encryption based on sensitive account data presence:
- Account Management operations (create, update, get)
- Rules Management operations with account references
- Contact Management operations with account associations
- Report Management operations returning account details
Certificate Management
Maintain both SSL and MLE certificates with proper renewal procedures to prevent authentication disruptions.
HTTP Header Construction
Construct proper HTTP headers for authenticated Payment Controls requests:
Content-Type: application/json
Accept: application/json
Authorization: Basic {base64-encoded-credentials}
x-pay-token: {encrypted-payload-when-account-data-present}Header Details:
- Authorization: Standard Basic authentication using VDP credentials
- Content-Type: Always application/json for Payment Controls APIs
- Accept: Always application/json for Payment Controls APIs
Message Level Encryption Implementation
Implement proper decryption for encrypted response payloads containing sensitive account information returned by the APIs.
Sensitive Data Identification: Apply MLE encryption to requests containing
- Account numbers and account identifiers
- Service keys and account references
- Card portfolio information
- Commercial card account details
Encryption Process
Encrypt the complete request payload using your MLE certificate and include the encrypted payload in the x-pay-token header while maintaining proper JSON structure for non-sensitive metadata fields.
Response Processing
Implement proper decryption for encrypted response payloads containing sensitive account information returned by the APIs.
Testing Authentication Connectivity
Validate your authentication setup using these testing approaches:
- Two-Way SSL Validation: Test mutual authentication using a simple account management API call
- MLE Encryption Test: Verify MLE encryption/decryption using an account creation operation in sandbox
- Header Verification: Confirm all required headers are properly constructed and accepted
- Certificate Validation: Test both SSL and MLE certificate functionality before production deployment
Sandbox Testing Considerations:
Remember that the sandbox environment provides only static values and a limited subset of possible requests. Code using API specifications rather than mimicking sandbox API explorer behavior, as you cannot execute all API functionality or see the full list of accurate error codes through the sandbox explorer.
Environment Authentication Variations
Authentication configuration considerations across environments:
- Sandbox Environment: Use sandbox-specific certificates for both SSL and MLE. Limited functionality testing available due to static values and restricted request subset.
- Production Environment: Use production certificates with live MLE encryption keys. Account ranges must be pre-configured during VPC implementation. Requires completed issuer authorization and contracting.
Environment-Specific Considerations:
- Certificate management varies between sandbox and production environments
- MLE encryption keys are environment-specific and cannot be interchanged
- Account range pre-configuration required for certification and production but not sandbox
- No regional variations in authentication requirements identified
Security Best Practices
Follow these security best practices for Payment Controls authentication:
- Certificate Security: Protect both SSL and MLE certificates with appropriate access controls and secure storage
- Key Rotation: Implement proper certificate renewal procedures to prevent authentication disruptions
- Payload Encryption: Always encrypt payloads containing account numbers, service keys, or other sensitive commercial card data
- Environment Separation: Maintain strict separation between sandbox and production certificates and credentials
- Access Controls: Implement proper access controls for certificate management and API credential storage
Authentication Troubleshooting
Common authentication issues and resolutions:
- SSL Handshake Failures: Verify Two-Way SSL certificate installation and mutual authentication configuration
- MLE Encryption Errors: Confirm MLE certificate validity and proper payload encryption implementation
- 401 Unauthorized: Check Basic authentication credentials, header construction, and certificate validity
- Certificate Validation Errors: Ensure proper certificate chain validation and environment-appropriate certificates
- Payload Decryption Issues: Verify MLE decryption implementation for response processing
VPC Error Codes
Product-specific error codes and troubleshooting guidance for Payment Controls, Rules Management, and related commercial card portfolio operations.
Error Handling Overview
Visa Commercial Payment Controls provides extensive product-specific error codes beyond standard VDP errors. These custom error codes support Payment Controls operations including account management, rules configuration, and reporting functionality, with specific error handling for commercial card scenarios.
Error responses include detailed information for troubleshooting payment control rule issues, account registration problems, and system processing challenges specific to commercial card management workflows.
Standard VDP Error Reference
In addition to the product-specific error codes documented below, Payment Controls APIs also return standard VDP error codes. Refer to the standard VDP error documentation for common HTTP status codes and general API error patterns.
Standard VDP errors typically cover authentication failures, malformed requests, and general system unavailability conditions that apply across all VDP APIs.
Error Response Format
Payment Controls APIs return structured error responses with consistent formatting:
{
"errorCode": "VPC-ERR-RM-1034",
"errorMessage": "Issuer BID validation failure",
"details": {
"accountNumber": "4***************",
"issuerBID": "12345",
"requestId": "req_pc123456",
"timestamp": "2026-03-31T17:30:00Z"
},
"suggestedAction": "Verify Issuer BID configuration and ensure proper setup during VPC implementation"
}Response Fields:
- errorCode: Specific product error code for programmatic handling
- errorMessage: Human-readable error description
- details: Context-specific information for troubleshooting including account references
- suggestedAction: Recommended resolution steps
Visa Commercial Payment Controls Response Codes
Possible success response codes returned from Visa Commercial Payment Controls requests.
- Workflow Sequence Validation: Account > Rules sequence before API calls
- Payload Size Monitoring: Monitor rule payload size to prevent errors
- Retry Logic: Implement exponential backoff for transient system errors
- Comprehensive Logging: Log error codes, request IDs, and sequence numbers for troubleshooting support
- API Specification Authority: Code against API specifications rather than sandbox explorer behavior
| Info Code ID | Info Code Description |
|---|---|
| VPC-RM-1000 | Successfully retrieved rules |
| VPC-RM-1001 | Rules were successfully set on the account |
| VPC-RM-1002 | Rules were successfully deleted from the account |
| VPC-RM-1003 | Account was successfully blocked |
| VPC-RM-1004 | Rules were validated |
| VPC-RM-1005 | Rules were successfully disabled |
| VPC-RM-1006 | Rules were successfully enabled |
| VPC-RM-1007 | Successfully created account |
| VPC-RM-1008 | Successfully retrieved account |
| VPC-RM-1009 | Successfully updated account |
| VPC-RM-1010 | Successfully deleted account |
Error Handling Best Practices
Implement these error handling strategies for robust Payment Controls integration:
- Workflow Sequence Validation: Account > Rules sequence before API calls
- Payload Size Monitoring: Monitor rule payload size to prevent errors
- Retry Logic: Implement exponential backoff for transient system errors
- Comprehensive Logging: Log error codes, request IDs, and sequence numbers for troubleshooting support
- API Specification Authority: Code against API specifications rather than sandbox explorer behavior
VPC Account Management API Error Codes
Error codes specific to commercial card account registration and management.
| ERROR CODE ID | ERROR CODE DESCRIPTION |
|---|---|
| VPC-ERR-AM-1000 | Please provide a valid Account Number. |
| VPC-ERR-AM-1001 | Please provide a valid Issuer BID. |
| VPC-ERR-AM-1002 | Please provide a valid VPC Client ID. |
| VPC-ERR-AM-1003 | Please provide a valid Customer Client ID. |
| VPC-ERR-AM-1004 | Please provide a valid Company Name. |
| VPC-ERR-AM-1005 | Please provide a valid Company ID. |
| VPC-ERR-AM-1006 | The isToken value provided does not meet the validation requirements. Please enter either 'true' or 'false'. |
| VPC-ERR-AM-1007 | Please provide a valid Token Reference ID. |
| VPC-ERR-AM-1008 | Please provide a valid First Name. |
| VPC-ERR-AM-1009 | Please provide a valid Last Name. |
| VPC-ERR-AM-1010 | Please provide a valid Dialing Code & Country Code for the Contact. |
| VPC-ERR-AM-1011 | Dialing Code or Country Code should not be entered for email contact. |
| VPC-ERR-AM-1012 | Please provide a valid Dialing Code. |
| VPC-ERR-AM-1013 | Please provide a valid Country Code. |
| VPC-ERR-AM-1014 | Please provide a valid Notification Channel & Format for the Contact. |
| VPC-ERR-AM-1015 | An Account may only have up to 3 active Contacts. |
| VPC-ERR-AM-1016 | The Action value provided does not meet the validation requirements. Please enter 'A' for add or 'D' for delete. |
| VPC-ERR-AM-1017 | Please provide a valid isToken value. |
| VPC-ERR-AM-1020 | DATABASE_CONNECTION_ERROR |
| VPC-ERR-AM-1021 | Please ensure that the Client-Issuer relation and Account Range is valid. |
| VPC-ERR-AM-1022 | This Account Number already exists in the Database. |
| VPC-ERR-AM-1023 | Please ensure that Account Number is valid and belongs to the provided Issuer & VPC Client ID. |
| VPC-ERR-AM-1024 | Please provide a valid Dialing Code & Country Code combination. |
| VPC-ERR-AM-1025 | Please enter a valid Language for Contacts. |
| VPC-ERR-AM-1026 | Please enter a valid Notification Channel for Contacts. |
| VPC-ERR-AM-1027 | Please enter a valid Notification Format for Contacts. |
| VPC-ERR-AM-1028 | Th Account-Contact relation was not found in the Database. |
| VPC-ERR-AM-1029 | The Language Code, Notification Channel or Notification Format does not belong to original Contact. |
| VPC-ERR-AM-1030 | Contact was not found in the Database. |
| VPC-ERR-AM-1031 | Contact already exists in the Database. |
| VPC-ERR-AM-1032 | Please ensure that the Contact field is populated with a valid value. |
| VPC-ERR-AM-1034 | Please enter unique Contacts in the request. |
| VPC-ERR-AM-1035 | Please enter a valid Request ID. |
| VPC-ERR-AM-1036 | Please enter a valid Source. |
| VPC-ERR-AM-1037 | Invalid input format. Please check the request payload. |
| VPC-ERR-AM-1090 | HazelCast Connection Error. |
| VPC-ERR-AM-1091 | Required Header Source is missing. |
| VPC-ERR-AM-1092 | Required Header Request ID is missing. |
| VPC-ERR-AM-1038 | Account is not found with the provided details. |
| VPC-ERR-AM-1039 | Unenrollment failed. |
| VPC-ERR-AM-1040 | The Old Contact and the New Contact provided are of different types. |
| VPC-ERR-AM-1041 | Company Contact update failed. |
| VPC-ERR-AM-1042 | Company Contact update was interrupted. |
| VPC-ERR-AM-1043 | No Account was found in the Database for the provided Customer Company ID, VPC Client ID & Issuer BID. |
| VPC-ERR-AM-1044 | The Old Contact and the New Contact provided cannot be the same. |
| VPC-ERR-AM-1045 | The Contacts provided does not match the Customer Company ID. |
| VPC-ERR-AM-1046 | Some of the Contacts being replaced, does not exist in the Database. |
| VPC-ERR-AM-1047 | Please update Contacts array. |
| VPC-ERR-AM-1048 | Please provide a Issuer BID in the Request Header. |
| VPC-ERR-AM-1049 | Please contact the System Administrator for further assistance. |
| VPC-ERR-AM-1050 | VIP interaction failed. |
VPC Rules Management API Error Codes
Error codes specific to payment control rules configuration and management.
| ERROR CODE ID | ERROR CODE DESCRIPTION |
|---|---|
| VPC-ERR-RM-1020 | GENERIC API ERROR |
| VPC-ERR-RM-1022 | Client ID provided in the Request Header does not meet validation requirements. |
| VPC-ERR-RM-1023 | Request ID provided in the Request Header does not meet validation requirements. |
| VPC-ERR-RM-1024 | Please provide Request ID in the Request Header. |
| VPC-ERR-RM-1025 | Please provide Client ID in the Request Header. |
| VPC-ERR-RM-1026 | Client ID provided in the Request Header does not meet validation requirements. |
| VPC-ERR-RM-1027 | Please provide Source Information in the Request Header. |
| VPC-ERR-RM-1028 | Source Information provided in the Request Header does not meet validation requirements. |
| VPC-ERR-RM-1029 | Please provide a Issuer BID in the Request Header. |
| VPC-ERR-RM-1030 | Currency value provided does not meet validation requirements. |
| VPC-ERR-RM-1021 | Issuer ID provided in Request Header does not meet validation requirements. |
| VPC-ERR-RM-1031 | Please provide a VPC Client ID. |
| VPC-ERR-RM-1032 | VPC Client ID provided does not meet validation requirements. |
| VPC-ERR-RM-1033 | Please provide an Issuer BID. |
| VPC-ERR-RM-1034 | Issuer BID provided does not meet validation requirements. |
| VPC-ERR-RM-1035 | Please provide an Account Number. |
| VPC-ERR-RM-1036 | Account Number provided does not meet validation requirements. |
| VPC-ERR-RM-1037 | The specific Account Number provided could not be found in the Database. |
| VPC-ERR-RM-1038 | Token Reference ID provided does not meet validation requirements. |
| VPC-ERR-RM-1039 | MCG Rule Action provided does not meet validation requirements. Expected values include 'Allow' or 'Block'. |
| VPC-ERR-RM-1040 | Timezone provided does not meet validation requirements. |
| VPC-ERR-RM-1041 | Start Date provided does not meet validation requirements. Expected format is mm/dd/yyyy. |
| VPC-ERR-RM-1042 | End Date provided does not meet validation requirements. Expected format is mm/dd/yyyy. |
| VPC-ERR-RM-1043 | Amount specified with Minor Units does not meet validation requirements. |
| VPC-ERR-RM-1044 | Please provide a Rule Currency Code for Amount Based Rules. |
| VPC-ERR-RM-1045 | Please provide Rules for Set Rules requests. |
| VPC-ERR-RM-1046 | Rule Schema provided does not meet validation requirements. |
| VPC-ERR-RM-1047 | Please remove duplicate Rule Codes. |
| VPC-ERR-RM-1048 | Please provide Amount Values for VPAS Rules. |
| VPC-ERR-RM-1049 | Maximum VPAS Size of 200 Exceeded. |
| VPC-ERR-RM-1050 | Rule Code provided does not meet validation requirements. |
| VPC-ERR-RM-1051 | Please provide both Minimum and Maximum Amount Values for TOLRNC Rules |
| VPC-ERR-RM-1052 | Please provide Currency Codes for TCUX Rules. |
| VPC-ERR-RM-1053 | Currency Code provided for TCUX Rule does not meet validation requirements. |
| VPC-ERR-RM-1054 | Please provide MCC Ranges for MCCB or MCCX Rules. |
| VPC-ERR-RM-1055 | Maximum MCC Size Exceeded for MCCB or MCCX rules. |
| VPC-ERR-RM-1056 | Please provide a MCC Range. |
| VPC-ERR-RM-1057 | Please provide the maxMcc and minMCC range values. |
| VPC-ERR-RM-1058 | MCC value provided does not meet validation requirements. |
| VPC-ERR-RM-1059 | Minimum MCC value should be less than maximum MCC value. |
| VPC-ERR-RM-1060 | Please provide the State Code for the DOM Rules. |
| VPC-ERR-RM-1061 | FIPS State Code provided does not meet the validation requirements. |
| VPC-ERR-RM-1062 | Please provide the Effective Time Periods for BUS Rules. |
| VPC-ERR-RM-1063 | Please provide the Country Codes for Location Based Rules. |
| VPC-ERR-RM-1064 | Country Code provided for Location Based Rules does not meet validation requirements. |
| VPC-ERR-RM-1065 | Maximum length size exceeded for Countries in Location Based Rules. |
| VPC-ERR-RM-1066 | Spend Limit Amount Tolerance provided does not meet validation requirements. |
| VPC-ERR-RM-1067 | Please provide a Spend Limit Amount. |
| VPC-ERR-RM-1068 | Spend Limit Amount provided for SPV Rule does not meet validation requirements. |
| VPC-ERR-RM-1069 | Maximum Authorization value provided does not meet the validation requirements. |
| VPC-ERR-RM-1070 | Please provide a Range Type for SPV Rule. |
| VPC-ERR-RM-1071 | Range Type provided for SPV Rule does not meet validation requirements. |
| VPC-ERR-RM-1072 | Recurring Day provided for Range Type Date Range does not meet validation requirements. |
| VPC-ERR-RM-1073 | Please provide an End Date for Range Type Date Range. |
| VPC-ERR-RM-1074 | End Date provided on the SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1075 | End Date provided for Range Type Recurring SPV does not meet the validation requirements. |
| VPC-ERR-RM-1076 | Day of the Week provided for Range Type Recurring SPV does not meet the validation requirements. |
| VPC-ERR-RM-1077 | Please provide Recurring Day for Range Type Recurring SPV. |
| VPC-ERR-RM-1078 | Recurring Day provided for SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1079 | Recurring Day provided for Range Type Weekly SPV does not meet the validation requirements. |
| VPC-ERR-RM-1080 | End Date provided for Range Type Weekly SPV does not meet the validation requirements. |
| VPC-ERR-RM-1081 | Please provide Day of the Week for Range Type Weekly SPV. |
| VPC-ERR-RM-1082 | Day of the Week provided for SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1083 | Recurring Day provided for Range Type Daily SPV does not meet the validation requirements. |
| VPC-ERR-RM-1084 | End Date provided for Range Type Daily SPV does not meet the validation requirements. |
| VPC-ERR-RM-1085 | Day of the Week provided for Range Type Daily SPV does not meet the validation requirements. |
| VPC-ERR-RM-1086 | Recurring Day provided for Range Type Monthly SPV does not meet the validation requirements. |
| VPC-ERR-RM-1087 | End Date provided for Range Type Monthly SPV does not meet the validation requirements. |
| VPC-ERR-RM-1088 | Day of the Week provided for Range Type Monthly SPV does not meet the validation requirements. |
| VPC-ERR-RM-1090 | Update Flag provided for SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1091 | Notify Option provided for SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1092 | Please provide a Threshold Amount for SPV Rule when Notify Option is selected as 'Everytime' or 'Once'. |
| VPC-ERR-RM-1093 | Threshold Amount provided for SPV Rule does not meet the validation requirements. |
| VPC-ERR-RM-1094 | Please provide the Recurring Day for Range Type selected as Recurring. |
| VPC-ERR-RM-1095 | Please provide the FIPS State Code. |
| VPC-ERR-RM-1096 | Effective Day provided for BUS Rule does not meet the validation requirements. |
| VPC-ERR-RM-1097 | Effective Time provided for BUS Rule does not meet the validation requirements. |
| VPC-ERR-RM-1098 | Start Time cannot be greater than End Time for BUS Rule. |
| VPC-ERR-RM-1099 | Either the 'Delete Current Rules' or 'Delete Future Rules' parameter, or both, must be true. |
| VPC-ERR-RM-1100 | Delete Current Rules does not meet validation requirements. |
| VPC-ERR-RM-1101 | Delete Future Rules does not meet validation requirements. |
| VPC-ERR-RM-1102 | The 'isDisable' flag is required in the request payload and must be set to either true or false. |
| VPC-ERR-RM-1103 | Rules are already enabled for this account. |
| VPC-ERR-RM-1104 | Rules are already disabled for this account. |
| VPC-ERR-RM-1105 | Block rule can be triggered only if disable is set to true. |
| VPC-ERR-RM-1106 | Rules expired, enabling rules failed |
| VPC-ERR-RM-1107 | Rules expired, disabling rules failed |
| VPC-ERR-RM-1111 | Update Flag provided for SPP Rule does not meet the validation requirements. |
| VPC-ERR-RM-1112 | Please provide Range Type for SPP Rule. |
| VPC-ERR-RM-1113 | Block ATM cash disbursement (ATM) and ATM cash disbursement amount limit (ATML) cannot be set together on an account. |
| VPC-ERR-RM-1114 | Block ecommerce transaction (ECOM) and Block ecommerce transaction over the amount limit (EAM) cannot be set together on an account. |
| VPC-ERR-RM-1115 | Block cross border transactions (XBR) and Cross border transactions with amount limit (XBRA) cannot be set together on an account. |
| VPC-ERR-RM-1116 | Allow merchants by Card Acceptor Code (CAID) and Block merchants by Card Acceptor Code (CAIDB) cannot be set together on an account. |
| VPC-ERR-RM-1117 | Allow states (DOM) and Block states (DOMB) cannot be set together on an account. |
| VPC-ERR-RM-1118 | Block counties (XBRB) and Allow countries (XBRX) cannot be set together on an account. |
| VPC-ERR-RM-1119 | Block merchants by their category code (MCCB) and Allow merchants by category code (MCCX) cannot be set together on an account. |
| VPC-ERR-RM-1120 | No Future rules were found in the Database. |
| VPC-ERR-RM-1121 | Internal Error: Error while extracting consumed authorization amounts and counts from VIP inquiry response. |
| VPC-ERR-RM-1122 | Please provide the same Rule Currency previously added for SPV. |
| VPC-ERR-RM-1123 | Start Date should be less than End Date. |
| VPC-ERR-RM-1124 | Please provide Rule Codes for all rules. |
| VPC-ERR-RM-1125 | Please provide Spend Limit Amount for SPV Rule. |
| VPC-ERR-RM-1126 | Please provide Velocity Details for SPV Rule. |
| VPC-ERR-RM-1127 | AccumulatedResentIndicator Flag provided for SPP Rule does not meet the validation requirements. |
| VPC-ERR-RM-1128 | Spend Limit Amount provided for SPP Rule does not meet validation requirements. |
| VPC-ERR-RM-1129 | Please provide Spend Limit Amount for SPP Rule. |
| VPC-ERR-RM-1130 | Please provide Velocity Details for SPP Rule. |
| VPC-ERR-RM-1131 | Number of policies for SPP Rule should not be more than 10. |
| VPC-ERR-RM-1132 | Please provide atleast one policy for SPP Rule. |
| VPC-ERR-RM-1133 | Spend Limit Amount Tolerance provided for the SPV rule does not meet the validation requirements. |
| VPC-ERR-RM-1134 | MCC Ranges cannot be overlapped in any policy. |
| VPC-ERR-RM-1135 | MCG Groups and MCC Ranges both cannot be provided for same policy in SPP rule. |
| VPC-ERR-RM-1136 | Please provide MCG Groups or MCC Ranges in the policy. |
| VPC-ERR-RM-1137 | MCG Groups cannot be duplicated in any policy. |
| VPC-ERR-RM-1138 | Please provide maximum 10 MCG Groups or MCC Ranges in one Policy. |
| VPC-ERR-RM-1139 | Day of the year is required for yearly range type. |
| VPC-ERR-RM-1140 | Day of the quarter is required for quarterly range type. |
| VPC-ERR-RM-1141 | Day of the week is required for weekly range type. |
| VPC-ERR-RM-1142 | Day of the month is required for monthly range type. |
| VPC-ERR-RM-1143 | Invalid range type provided. |
| VPC-ERR-RM-1144 | Day of the month must be between 1 and 28. |
| VPC-ERR-RM-1145 | Day of the year must be between 1 and 365. |
| VPC-ERR-RM-1146 | Day of the quarter must be between 1 and 88. |
| VPC-ERR-RM-1147 | Day of the week must be between 1 and 7. |
| VPC-ERR-RM-1148 | Provided MCG not found. |
| VPC-ERR-RM-1149 | The specific Rule Currency requested could not be found in the Database. |
| VPC-ERR-RM-1150 | Amount Values provided for VPAS Rule does not meet the validation requirements. |
| VPC-ERR-RM-1151 | Please provide Currency Codes for TCUX Rule. |
| VPC-ERR-RM-1152 | Maximum length size exceeded for Currency Code in TCUX Rule. |
| VPC-ERR-RM-1153 | The specific Currency Codes requested for TCUX Rule could not be found in the Database. |
| VPC-ERR-RM-1154 | Minimum OR Maximum amount provided for TOLRNC Rule does not meet the validation requirements. |
| VPC-ERR-RM-1155 | Please provide the Minimum and Maximum Amounts for TOLRNC Rule. |
| VPC-ERR-RM-1156 | Please provide the Amount for the Rule. |
| VPC-ERR-RM-1157 | The specific Country Code requested for Location Rule could not be found in the Database. |
| VPC-ERR-RM-1158 | Please provide the Card Acceptor ID for CAID or CAIDB rules. |
| VPC-ERR-RM-1159 | Card Acceptor ID must not exceed 15 characters. |
| VPC-ERR-RM-1160 | Card Acceptor ID provided does not meet the validation requirements. |
| VPC-ERR-RM-1161 | Duplicate Card Acceptor Codes were found within Acquiring ID. |
| VPC-ERR-RM-1162 | Please provide the Acquiring ID for CAID or CAIDB rules. |
| VPC-ERR-RM-1163 | Acquiring ID must not exceed 11 characters. |
| VPC-ERR-RM-1164 | Acquiring ID provided does not meet the validation requirements. |
| VPC-ERR-RM-1165 | Duplicate Acquiring ID is not allowed on CAID or CAIDB Rules. |
| VPC-ERR-RM-1166 | Acquiring ID and Card Acceptor ID combination count is exceeding maximum limit allowed. |
| VPC-ERR-RM-1167 | PerDiem Values cannot be empty |
| VPC-ERR-RM-1168 | PerDiem Values size cannot exceed 5 |
| VPC-ERR-RM-1169 | Please provide a MCG value. |
| VPC-ERR-RM-1170 | MCG length cannot exceed 5 characters. |
| VPC-ERR-RM-1171 | MCG length must be 3 characters long. |
| VPC-ERR-RM-1172 | Please provide the Amount Limit. |
| VPC-ERR-RM-1173 | Amount Limit provided does not meet the validation requirements. |
| VPC-ERR-RM-1174 | No existing rules were found in the Database. |
| VPC-ERR-RM-1175 | The specific Timezone provided does not exist in the Database. |
| VPC-ERR-RM-1176 | Start Date cannot be in the past. |
| VPC-ERR-RM-1177 | End Date cannot be in the past. |
| VPC-ERR-RM-1178 | Duplicate Effective Day was found for the BUS Rule. |
| VPC-ERR-RM-1179 | Spend Limit Amount Tolerance provided for the SPV rule does not meet the validation requirements. |
| VPC-ERR-RM-1180 | JSON request provided is invalid. |
| VPC-ERR-RM-1181 | Minimum Amount cannot be greater than Maximum Amount for TOLRNC Rule. |
| VPC-ERR-RM-1182 | Start Time is required for BUS Rule. |
| VPC-ERR-RM-1183 | End Time is required for BUS Rule. |
| VPC-ERR-RM-1184 | Effective Start Time provided for BUS Rule does not meet the validation requirements. |
| VPC-ERR-RM-1185 | Effective End Time provided for BUS Rule does not meet the validation requirements. |
| VPC-ERR-RM-1186 | Orphan CAIDs cannot be duplicated in CAID rule. |
| VPC-ERR-RM-1187 | Token Reference ID is not allowed on Validate Rules Requests. |
| VPC-ERR-RM-1188 | Issuer BID is not allowed on Validate Rules Requests. |
| VPC-ERR-RM-1189 | VPC Client ID is not allowed on Validate Rules Requests. |
| VPC-ERR-RM-1190 | Account Number is not allowed on Validate Rules Requests. |
| VPC-ERR-RM-1191 | Please provide the Effective Day for BUS Rule. |
| VPC-ERR-RM-1192 | Please provide the Currency Code for TCUX Rule. |
| VPC-ERR-RM-1193 | Currency Code provided for TCUX Rule does not meet validation requirements. |
| VPC-ERR-RM-1194 | MCC Ranges are overlapped for MCCB rule. |
| VPC-ERR-RM-1195 | MCC Ranges are overlapped for MCCX rule. |
| VPC-ERR-RM-1196 | Create Account is required |
| VPC-ERR-RM-1197 | Set Rules is required |
| VPC-ERR-RM-1198 | Issuer not found |
| VPC-ERR-RM-1199 | Issuer notification settings not found |
| VPC-ERR-RM-1200 | AccumulatedSpendResetIndicator provided does not meet the validation requirements. |
| VPC-ERR-RM-1201 | No current rules were found in the Database. |
| VPC-ERR-RM-1202 | An invalid VPC Client ID has been entered |
| VPC-ERR-RM-1203 | An invalid Customer Client ID has been entered |
| VPC-ERR-RM-1204 | An invalid company name has been entered |
| VPC-ERR-RM-1205 | An invalid company ID has been entered |
| VPC-ERR-RM-1206 | An invalid is token value has been entered. Please enter either 'true' or 'false' |
| VPC-ERR-RM-1207 | An invalid token reference ID has been entered |
| VPC-ERR-RM-1208 | An invalid first name has been entered |
| VPC-ERR-RM-1209 | An invalid last name has been entered |
| VPC-ERR-RM-1210 | Please enter a valid dialing code & country code for the contact |
| VPC-ERR-RM-1211 | Dialing code or country code should not be entered for email contact |
| VPC-ERR-RM-1212 | An invalid dialing code has been entered |
| VPC-ERR-RM-1213 | An invalid country code has been entered |
| VPC-ERR-RM-1214 | Please enter a valid notification channel & format for the contact |
| VPC-ERR-RM-1215 | An account may only have up to 3 active contacts |
| VPC-ERR-RM-1216 | An invalid action has been entered. Please enter 'A' for add or 'D' for delete |
| VPC-ERR-RM-1217 | Please provide a valid isToken value |
| VPC-ERR-RM-1218 | Please ensure that the contact field is populated with a valid value |
| VPC-ERR-RM-1219 | The language code, notification channel or notification format does not belong to original contact |
| VPC-ERR-RM-1220 | Contact not found |
| VPC-ERR-RM-1221 | Please enter unique contacts in the request |
| VPC-ERR-RM-1222 | Please enter a valid language for contacts |
| VPC-ERR-RM-1223 | Please enter a valid notification channel for contacts |
| VPC-ERR-RM-1224 | Please enter a valid notification format for contacts |
| VPC-ERR-RM-1225 | Dialing code & country code combination is invalid |
| VPC-ERR-RM-1226 | Please enter a valid request ID |
| VPC-ERR-RM-1227 | Please enter a valid source |
| VPC-ERR-RM-1228 | DATABASE_CONNECTION_ERROR |
| VPC-ERR-RM-1229 | Please ensure that client-issuer relation and account range is valid |
| VPC-ERR-RM-1230 | Account number already exists |
| VPC-ERR-RM-1231 | Account does not exist. Please ensure that account number is valid and belongs to the provided issuer & vpc client id |
| VPC-ERR-RM-1232 | Account-Contact relation not found |
| VPC-ERR-RM-1233 | Contact already exists |
| VPC-ERR-RM-1234 | HazelCast Connection Error |
| VPC-ERR-RM-1235 | Notification Channel or Format is not valid for %s contact as per the issuer settings |
| VPC-ERR-RM-1236 | Payload size exceeds maximum allowed size of 30720 bytes |
| VPC-ERR-RM-1237 | An invalid action has been entered |