visa offers platform - visa developer center penetration testing ... standard terms regarding the...

Visa Offers Platform

Implementation Guide

Effective Date: August 2015

Visa Confidential

Important Information on Confidentiality and Copyright

© 2015 Visa. All Rights Reserved.

Notice: This information is proprietary and CONFIDENTIAL to Visa. It is distributed to Visa participants

for use exclusively in managing their Visa programs. It must not be duplicated, published, distributed

or disclosed, in whole or in part, to merchants, cardholders or any other person without prior written

permission from Visa.

The trademarks, logos, trade names and service marks, whether registered or unregistered (collectively

the “Trademarks”) are Trademarks owned by Visa. All other trademarks not attributed to Visa are the

property of their respective owners.

Note: This document is not part of the Visa Rules. In the event of any conflict between any content in

this document, any document referenced herein, any exhibit to this document, or any

communications concerning this document, and any content in the Visa Rules, the Visa Rules

shall govern and control.

Contents

Visa Offers Platform - Implementation Guide

August 2015 Visa Confidential i

Contents

Contents .............................................................................................................................................................................................i

Visa Offers Platform Implementation Guide .................................................................................................................... 1

Overview....................................................................................................................................................................................... 1

Document Purpose and Audience...................................................................................................................................... 1

1 Visa Offers Platform Implementation ........................................................................................................................ 2

1.1 Overview ............................................................................................................................................................................ 2

1.2 Implementation Process Overview .......................................................................................................................... 2

2 Security Requirements ...................................................................................................................................................... 3

2.1 Overview ............................................................................................................................................................................ 3

2.2 Security Assessment Process...................................................................................................................................... 4

2.2.1 Initial Review ............................................................................................................................................................. 4

2.2.2 Penetration Testing ................................................................................................................................................ 5

2.2.3 Final Review............................................................................................................................................................... 5

3 Web Service Integration Options................................................................................................................................. 5

3.1 Overview ............................................................................................................................................................................ 5

3.2 Visa Developers Center ................................................................................................................................................ 6

3.3 Web Services .................................................................................................................................................................... 7

3.3.1 Enrollment APIs ....................................................................................................................................................... 7

3.3.2 Merchant APIs .......................................................................................................................................................... 7

3.3.3 Offer APIs ................................................................................................................................................................... 8

3.3.4 Fulfillment API .......................................................................................................................................................... 8

4 Migration of Existing Programs.................................................................................................................................... 9

4.1 Overview ............................................................................................................................................................................ 9

4.2 Member Migration Process and options ............................................................................................................... 9

4.2.1 Defining Scope......................................................................................................................................................... 9

4.2.2 Web Service Implementation ...........................................................................................................................10

4.2.3 Web Service Execution & Testing ...................................................................................................................10

Contents


ii Visa Confidential August 2015

4.3 Merchant Migration Process and Options ..........................................................................................................11

4.3.1 Defining Scope.......................................................................................................................................................11


4.3.3 Web Service Execution & Timing....................................................................................................................12

4.4 Offer Migration Process and options....................................................................................................................12

4.4.1 Defining Scope.......................................................................................................................................................12


4.4.3 Web Service Execution & Timing....................................................................................................................13

5 Consumer Enrollment......................................................................................................................................................13

5.1 Overview ..........................................................................................................................................................................13

5.2 Secure API Enrollment ................................................................................................................................................14

5.3 Visa Hosted Enrollment..............................................................................................................................................16

6 Merchant Onboarding and Offer Setup ..................................................................................................................20

6.1 Overview ..........................................................................................................................................................................20

6.2 Visa Offers Platform Client Services Center (CSC)............................................................................................20

6.3 Merchant Identification and Onboarding (small and mid-size businesses)...........................................20

6.4 Merchant Onboarding (for large businesses) ....................................................................................................22

6.5 Offer Setup and Publishing.......................................................................................................................................23

7 Administrative Requirements ......................................................................................................................................24

7.1 Billing.................................................................................................................................................................................24

7.2 Reporting .........................................................................................................................................................................24

7.3 Secure File Transfer Protocol (SFTP) Setup .........................................................................................................24

8 Marketing and Legal Reviews of Consumer-Facing Content.........................................................................25

8.1 Overview ..........................................................................................................................................................................25

8.2 Implementation/Pre-Launch Reviews ...................................................................................................................26

8.3 Ongoing/Post-Launch Reviews ...............................................................................................................................26

9 Transition to Account Management .........................................................................................................................27

9.1 Overview ..........................................................................................................................................................................27

9.2 BAU Operations.............................................................................................................................................................27

9.3 Issues Management.....................................................................................................................................................27

9.4 Consultation ...................................................................................................................................................................28

Contents


August 2015 Visa Confidential iii

Glossary ..........................................................................................................................................................................................29

Visa Offers Platform Implementation

Visa Offers Platform - Web Services Implementation Guide

August 2015 Visa Confidential 1

Visa Offers Platform Implementation Guide

The Visa Offers Platform Implementation Guide outlines the process and requirements for digital

media platforms (referred to in this document as “program providers”) to integrate with the Visa

Offers Platform.

Overview

The Visa Offers Platform provides digital media program providers with access to qualified Visa

transaction data of enrolled cardholders. By integrating with the Visa Offers Platform, program

providers can enhance their own loyalty and offers programs in new and powerful ways.

The Visa Offers Platform accesses the VisaNet authorization stream to monitor enrolled cardholder

transactions and send relevant notifications to program providers. Using simple APIs, program

providers can integrate Visa Offers Platform capabilities and transaction data into their own web and

mobile applications.

This document will outline the process and requirements for integrating with the Visa Offers Platform.

Document Purpose and Audience

The Visa Offers Platform Implementation Guide is intended for program providers that are considering

using the Visa Offers Platform to integrate with and enhance their own loyalty and offers platforms.

This document describes process and requirements for integrating with the Visa Offers Platform, but

does not create any obligation on Visa’s part to make any of the listed capabilities available to a

particular program provider. Visa’s provision of any element or function of the Visa Offers Platform is

subject to a written agreement between Visa and the applicable program provider containing Visa’s

standard terms regarding the uses of the Visa Offers Platform and Visa transaction data.

Overview


2 Visa Confidential August 2015

1 Visa Offers Platform Implementation

1.1 Overview

This section will provide detailed information on key requirements to implement a Visa Offers

program. Visa will work closely with the program provider to define, solution, implement and fully test

the integration with the Visa Offers Platform prior to launch.

The following implementation timeline provides a high level overview of the key work streams for

launch of a Visa Offers platform program

Please note that:

The phases are serial but can overlap slightly

The duration of each phase is dependent on the complexity of the program and

The phases can be repeated in a phased implementation approach

1.2 Implementation Process Overview

The implementation process consists of a series of required tasks. This document is organized to address

the various phases that must be addressed before a program provider can go into operation with VOP.

Section 2 - Security Requirements: The Visa Offers Platform accesses the VisaNet authorization

stream, and as a result there is a strong emphasis on security and control.

Section 3 - Web Service Integration Options: The Visa implementation team will collaborate with

the program provider to identify the web service options required to support the program.

Section 4 - Migration of Existing Programs: If there is an existing program with cardholders,

merchants and offers, the Visa implementation team will collaborate with the program provider to

design and execute a migration plan that ensures minimal interruption of overall services and

offers.

Section 5 - Consumer Enrollment: Once security requirements have been reviewed and web service

details discussed, defining the process to submit cardholder data is critical.

Security Requirements



Section 6 - Merchant Onboarding and Offer Setup: The process begins with identifying

participating merchants either through the SearchMerchant API and then onboarding targeted

merchants by means of the OnboardMerchant API.

Section 7 - Administrative Requirements: This section covers billing, reporting and SFTP setup.

Section 8 - Marketing and Legal Reviews of Consumer-Facing Content

Section 9 - Transition to Account Management: This section describes the process of handing off

oversight from the Visa implementation team to business as usual program administration.

During the implementation process, a number of document artifacts will be produced in support of the

program. The most important of these will be the program Implementation Brief. This document will

describe the solution design and all the agreed upon configuration options for the implementation. It

will be used for reference and to assess all program changes after completion of the initial

implementation.

2 Security Requirements

2.1 Overview

A Security Assessment by a Visa Security Analyst is required for any program that integrates with the

Visa Offers platform. Depending on the review, a penetration test may be required. Key considerations

include:

Whether the program provider is collecting a PAN (Personal Account Number for a cardholder

account) and providing it to Visa as part of the enrollment process (vs. using a Visa-hosted

enrollment page)

The data the program provider receives from Visa

program provider’s PCI (Payment Card Industry) Compliance documentation and recent

penetration test results

In most cases and without limitation, there are two security requirements that must be met before a

program provider who handles PANs will be allowed to interact with Visa informational systems in the

final production environment.

PCI Data Security Standard

- All program providers must be PCI compliant to use Visa’s Web services APIs. A 3rd party

consulting organization must perform a PCI audit on an annual basis in order to demonstrate

compliance. Please refer to https://www.pcisecuritystandards.org for more information.

Penetration Testing

https://www.pcisecuritystandards.org/

Security Assessment Process



A penetration test assesses a computer system’s security by simulating attacks from malicious

outsiders. All program providers must pass a penetration test performed by a 3rd party prior to

being given access to any of Visa’s information systems.

- A penetration test will be required if the program provider

Has not completed a 3rd party PCI audit in the past year, or

The recent penetration test did not include in its scope all internal and external systems

and applications that will handle Visa data

- To pass Visa Security Assessment, the pen test report must meet two requirements:

All critical and high risk findings must be successfully remediated with retest results

included in the pen test report, and

All other risk findings must include a plan and timeline for remediation

A penetration test is generally included as part of a 3rd party PCI audit. If the program

provider has recently completed a 3rd party PCI audit, the penetration test may be waived

based on review of PCI documentation at Visa’s sole discretion.

Please note that Visa may revise its requirements and process at any time.

2.2 Security Assessment Process

2.2.1 Initial Review

The initial security review is expected to take up to three weeks. After the program implementation

kickoff, the program provider may be asked to complete the following security assessment documents

(other documents may also be required):

SSDLC(Secure System Development) Engagement Form

Third Party Risk Assessment Questionnaire

GIS (Global Information Security) Assessment External Checklist

In addition, the program provider will be asked to provide any supporting materials to the above,

including PCI Compliance documentation.

Once the program provider has sent these required documents to Visa, the Implementation Manager

for the program will formally open a Security Assessment Request with Visa Global Information Security.

The initial review takes about two weeks to complete, which typically includes one or two meetings

between the program provider and the Visa Security Analyst.

If the Security Assessment passes successfully, the Visa Security Analyst will clear the project for

production integration. If new penetration test is required, integration in the final production

environment cannot proceed until the test is complete and the report meets the security requirements.

Web Service Integration Options



2.2.2 Penetration Testing

If a new penetration test is required for the program, the program provider will need to engage a 3rd

party to perform the pen test, which usually takes a minimum of six weeks to complete:

Weeks 1 and 2: identify 3rd party consulting organization

Week 3: scope the test with 3rd party and Visa security team

Week 4: perform pen test

Week 5: remediate and retest

Week 6: complete pen test report

The Visa Security Analyst can suggest 3rd party pen testing consultants. Program provider is solely

responsible for engaging the 3rd party consultant.

2.2.3 Final Review

Once the pen test report is complete, the Security Analyst will complete a final security review. If there

are issues found during the pen test, a resolution by the program provider and the 3rd party consultant

may be required.

3 Web Service Integration Options

3.1 Overview

The Visa Offers Platform delivers various types of information to program provider systems,

depending on the program provider’s agreement with Visa. The Visa Offers Platform offers multiple

message delivery options, including RESTful APIs for simple integration. Event notifications can be

formatted in SOAP, JSON or straight XML based on the program provider’s preference. All modes

must abide by Visa’s standard security protocols for secure data transmission and storage as may be

amended from time to time.

The Visa Implementation Manager and Platform Development specialist will work with the program

provider to define the web service integration options that are appropriate for each program.

The following is an overview of how to access technical documentation via the Visa Developers Center

as well as information on the API’s available to program providers.

Visa Developers Center



3.2 Visa Developers Center

Visa has established a Developers Center that allows self-service access to technical documentation

for approved program providers. In order for the program provider to be approved, either a signed

contract or Non-disclosure Agreement (NDA) with Visa is required. Obtaining access is a two-step

process as follows:

Program provider signs up for a Visa Developers Center account at

https://developer.visa.com/users/sign_up and agrees to Visa’s standard terms and conditions.

Once account credentials have been established, program provider requests access to the Visa

Offers Platform documentation at https://developer.visa.com/vop.

A Visa representative will review the request and will grant access to the platform documentation and

once eligibility has been verified as per the requirements above.

The following are examples of the types of documentation the program provider can expect to find in

the Developers Center:

Getting Started Guide – Includes:

- program Overview

- Enrollment Life Cycle

- Express Enrollment Life Cycle

- Offer Life Cycle

- SOAP Message Format

- Web Service On-boarding

- Visa Digital Signing Certificate

WSDL - Web Services Description Language for supported public Web Service operations.

API Documents

- Enrollment API

- Merchant On-Boarding API Refer

- Offers API

- Statement Credit API

“Sandbox” access environment support

- Credentials and certificate

- SOAPUI Sandbox Installation Guide

- SOAPUI Sandbox Test Project

Outbound Communications/Purchase Verification Endpoint Messaging

Overview document and sample messages

Production access information

https://developer.visa.com/users/sign_up

https://developer.visa.com/vop

https://developer.visa.com/vop/document/download/10517/original?1435293798

https://developer.visa.com/vop/document/download/10696/original?1435293752

Web Service Integration Options



This document

Any additional questions regarding the Developers Center should be directed to the designated Visa

Implementation Manager, or to the designated Developers Center support email at vop-vdc-

[email protected].

3.3 Web Services

The following are the available API calls for use by the program provider for their Visa Offers Platform

program.

3.3.1 Enrollment APIs

The enrollment life cycle includes the following steps:

Enroll – Provides a card number and associated profile data to VOP. VOP returns unique

identifiers for both the card and the profile. After initial enrollment these identifiers should be

used in subsequent VOP interactions.

SaveCard – Adds a card number to a profile. The maximum number of cards per profile is

configurable and identified during the implementation process.

DeleteCard – Removes a card from a profile.

Unenroll – Removes a profile.

3.3.2 Merchant APIs

Visa’s merchant database has the following hierarchy:

Enterprise – For example “GAP”

Merchant – For example Old Navy, Banana Republic, Gap

Store

To obtain merchant data program providers can use one of the various SearchMerchant APIs to collect

Visa merchant profiles. After examining the returned profiles a program provider uses selected

profiles to include in their offers by calling the OnboardMerchants API.

SearchMerchantDetailsByAttribute – Returns merchant profile data when the merchant’s name and

Zip Code are known at a minimum.

SearchMerchantDetailsByTransaction – Returns merchant data when provided with the details of a

specific transaction at the merchant.

SearchMerchant – Provides the capability to run wild-card searches on the following attributes:

- Franchise Name

mailto:[email protected]

mailto:[email protected]

Web Services



- Enterprise Name

- Merchant Name

- Store Name

Among others.

OnboardMerchants - Includes a merchant in a community. Once onboarded a merchant cannot

be un-onboarded. After a program provider has onboarded a merchant the program provider can

set up offers for enrollees at a merchant.

3.3.3 Offer APIs

Visa Offers provides the Client Service Center (CSC), a GUI environment, as the principal means of

setting up an offer. An offer can also be created via the CreateOffer API provided that an offer

“template” has previously been set up for the offer in the CSC. Templates simplify the offer creation

process by allowing a web service user to modify only salient details of an offer without needing to

identify the unchanging components.

CreateOffer – Defines the salient parameters of an offer. Requires that an offer “template” has

previously been established by means of the Client Service Center. Offer parameters may include:

- Timeframe

- Merchants

- Benefits

- Minimum spend

- …

SaveOfferActivation – Activates an offer for an enrollee.

OfferDeactivation – Deactivates an offer for an enrollee.

UpdateOffer – Deletes an offer.

3.3.4 Fulfillment API

Once an enrollee has collected a benefit, a program provider specifies the benefit’s statement

credit by means of the SaveStatementCredit API.

SaveStatementCredit

Migration of Existing Programs



4 Migration of Existing Programs

4.1 Overview

When a Visa Offers Platform implementation is being integrated with or replacing an existing platform,

current members, merchants, and offers may need to be migrated to Visa Offers. To minimize any risk

of interrupted service to the program provider, cardholders and merchant partners it is important to

outline the migration of the following components well in advance of the program’s targeted launch

date. The program provider and Visa Implementation Manager will work together to define this

migration plan.

4.2 Member Migration Process and options

4.2.1 Defining Scope

In preparation for migrating an existing group or members, the assigned Visa Implementation Team will

work with each program provider to define metrics including the following:

Member Base

- How many members are enrolled in the existing program?

- How many unique cards are enrolled in the existing program? Of those, how many are

specifically Visa cards?

Enrollment/Unenrollment Statistics

- On a daily/weekly/monthly basis, about how many new members (or cards) are enrolled into

the program?

- On a daily/weekly/monthly basis, about how many members (or cards) are unenrolled from the

program?

Member/Card Activity

- Are expiration dates for cards captured as part of card enrollment?

If yes, are cards automatically unenrolled as part of an existing card expiration process?

If no, is there currently any process in place to monitor or cleanup cards based on member

or card activity?

Technical Implications

- What member/card information is captured as part of member/card enrollment?

- What member/card information would Visa need to capture and store as part of the

migration?

Member Migration Process and options



Upon defining the criteria above, the Visa Implementation Team will assess the existing volumes and

processes to scope the migration efforts and outline the anticipated timeline.

4.2.2 Web Service Implementation

Development

- The migration of members will be performed through a series of API calls using the standard

Enroll web service (see VOP Enrollment API).

- As part of the web service implementation of the Visa Implementation Team will work with

each program provider to define the required fields that would need to be passed to Visa as

well as help to map these fields back to the program provider’s systems and databases as

needed.

- The Visa Implementation Team will also work with the program provider to define expected

return values and error messages as documented in the VOP Enrollment API.

QA/Integration

- Upon completion of development, the Visa Implementation Team will coordinate a live

working session between the program provider’s technical team and Visa’s QA/Integration

team to test the Enroll web service.

4.2.3 Web Service Execution & Testing

Dependencies

- Enroll web service passes QA/Integration Testing

- Approval from Visa Security Team for production readiness

- Access granted to Production Environment

Throttling

- For the purpose of migration, the Visa Implementation Team will need to understand how

many simultaneous web service calls can be made in a given period (e.g. 5 calls per second) to

determine how long the migration process will take.

Scheduling

- Based on the volume of members to be migrated as well as the defined rate at which the web

service calls will be made, the Visa Implementation Team may also coordinate scheduling the

migration during off-peak, low-traffic times of the day.

Migration of Existing Programs



4.3 Merchant Migration Process and Options


As the first step in defining the scope of work required to migrate an existing group of members, the

Visa Implementation Manager and program provider will work together to define the following metrics:

Merchant Base

- How many merchants (e.g. Starbucks) are enrolled in the existing program?

- If different, how many merchant locations (e.g. Starbucks at Bridgepointe Shopping Center in

Foster City, CA) are enrolled in the existing program?

Onboarding/Offboarding Statistics

- On a daily/weekly/monthly basis, about how many new merchants (or merchant locations) are

added to the program?

- On a daily/weekly/monthly basis, about how many merchants (or merchant locations) are

removed from the program?


- What member/card information is captured as part of member/card enrollment?

- What member/card information would Visa need to capture and store as part of the

migration?


Development

- The migration of merchants will be performed through a series of API calls using the standard

Search / OnboardMerchants web service (see VOP Merchant Onboarding API).

- As part of web service implementation, the Visa Implementation Team and program provider

will work together to define the required fields that would need to be passed to Visa as well as

help to map these fields back to the program provider’s systems and databases.

- The Visa Implementation Team and program provider will also work together to define

expected return values and error messages as documented in the VOP Merchant Onboarding

API.

QA/Integration

- Upon completion of development, the Visa Implementation Team will coordinate a live

working session between the program provider’s technical team and Visa’s QA/Integration

team to test the OnboardMerchants web service.

Offer Migration Process and options



4.3.3 Web Service Execution & Timing

Dependencies

- Search Merchant web services passes QA/Integration testing

- OnboardMerchants web service passes QA/Integration testing

- Approval from the Visa Security Team for production readiness


Throttling

- For the purpose of migration, the Visa Implementation Team will need to understand how

many simultaneous web service calls can be made in a given period (e.g. 5 calls per second) to


Scheduling

- Based on the volume of merchants to be migrated as well as the defined rate at which the web



4.4 Offer Migration Process and options


Offer Structure

- How many total offers does the existing program currently have?

- What is the qualification process for members to receive these offers?

Offer Statistics

- On a daily/weekly/monthly basis, about how many new offers are added to the program?

- On a daily/weekly/monthly basis, about how many offers expire or are removed from the

program?


What offer information is captured and stored as part of offer migration?


Development

- The migration of offers will be performed through a series of API calls using the standard

CreateOffer web service (see VOP Offer API).

Consumer Enrollment



- As part of the web service implementation, the Visa Implementation Team and program

provider will work together to define the required fields that would need to be passed to Visa

as well as help to map these fields back to the program provider’s systems and databases.

- The Visa Implementation Team and program provider will also work together to define

expected return values and error messages as documented in the VOP Offer API.

QA/Integration: Upon completion of development, the Visa Implementation Team will coordinate

a live working session between the program provider’s technical team and Visa’s QA/Integration

team to test the CreateOffer web service.

4.4.3 Web Service Execution & Timing

Dependencies

- CreateOffer web service passes QA/Integration Testing

- Approval from Visa Security Team for production readiness


Throttling

For the purpose of migration, the Visa Implementation Team will need to understand how many

simultaneous web service calls can be made in a given period (e.g. 5 calls per second) to


Scheduling

- Based on the volume of offers to be migrated as well as the defined rate at which the web



- Depending on the structure of the offer setup, time may also need to be allotted for offer

publishing.

5 Consumer Enrollment

5.1 Overview

Program providers are responsible for enrolling cardholders to participate in their offers and rewards

programs. To enable Visa Offers Platform capabilities, an eligible Visa card must be enrolled into the

Visa Offers Platform. Visa supports three primary enrollment methods:

Secure API for integration with PCI-compliant websites and mobile apps:

- For program providers who want to integrate enrollment into an existing user experience, such

as a loyalty program site or mobile application, Visa offers a full suite of integration web

services (APIs) supporting enrollment and unenrollment.

Secure API Enrollment



- The Cardholder Enrollment API enables the program provider to completely manage the

cardholder enrollment experience within their own website or mobile application,

communicating with Visa in the background to exchange enrollment data.

- Note: This option requires that the program provider’s enrollment site or application is PCI

DSS/CISP compliant.

Batch Enrollment

- Program providers may also choose to enroll members in batch via the batch enrollment API

as described in VOP Enrollment API .

Visa-hosted enrollment website:

- Visa can host and support a co-branded cardholder enrollment website that includes all

required information fields to allow cardholders to enroll via a mobile or desktop web browser.

Following successful enrollment, Visa can transmit enrollment data to a program provider’s

platform via a secure API, or via a batch file exchange. Please refer to VOP Express

Enrollment for details.

The following sections describe the requirements and work streams for each consumer enrollment

option.

5.2 Secure API Enrollment

For program providers who are already PCI compliant or are in the process of becoming so, enrolling

cardholders via Visa’s enrollment web services and batch enrollment are the preferred methods for

transmitting data to Visa.

When electing this option, initial cardholder enrollment and any updates to enrollment are done in

one of the following ways:

Web service calls. Refer to VOP Enrollment API . There are web services to handle enrollment

use cases: Enroll and unenroll. The use cases include the following: initial enrollment, add card,

remove card, and unenroll cardholder.

Batch enrollment. Refer to VOP Enrollment API. The program provider may also choose to

deliver a comma delimited file via SFTP to a VOP server to enroll cardholders in batch. Refer to

Section 7.3 - Secure File Transfer Protocol (SFTP) Setup

Exact data fields to be provided by the program provider to Visa will be mutually agreed upon and

recorded in the technical specification document, but at minimum must include the PAN (Personal

Account Number) for the enrolled card. Additional fields that are typically included are enrollee first

and last name, PAN expiration date, billing zip code, and external/program provider id for the

cardholder and/or specific card.

Key Considerations when using Visa’s Secure APIs to enroll cards

Consumer Enrollment



- In order to enroll cards in a Visa Offers program, the program provider must have the

appropriate consents/permissions from their enrolled consumers for Visa to monitor their card

activity and provide transaction data to the program provider as described in the Agreement

between Visa and the program provider. Following execution of the Agreement and prior to

program launch:

Visa’s legal department must review and approve all existing terms and conditions and

privacy policies for the program related to the Visa services prior to the launch, as well as

any usage of the Visa brand mark. The program provider remains responsible for all

aspects of the program including all compliance with applicable law.

- Enrollment Marketing

All consumer-facing marketing materials to promote program enrollment are subject to

review and approval by Visa’s marketing and legal departments. This includes any usage of

Visa’s brand mark. Approval by the Visa marketing and legal departments is required prior

to the program provider’s distribution of these materials.

Examples of materials subject to review include email invitations to enroll, the program

landing page, banner ads, social media messaging, in-store messaging, radio ads and

printed materials. Please note that this list is not exhaustive and is provided for illustrative

purposes only. Any and all consumer marketing messaging is subject to review and

approval by Visa’s legal and marketing departments.

- Administrative/Credentials: Prior to utilizing Visa’s secure APIs for the first time, there are a few

prerequisites for access:

A Visa Business Identifier or “BID”

If a program provider has an existing business relationship with Visa there may already be

a BID on file. If not, the implementation manager for the Visa Offers program will facilitate

the application process with Visa’s licensing team. Visa requires a BID in order to apply for

Visa Online (VOL) access.

Visa Online or “VOL” Access

Once a program provider has been assigned a BID by Visa licensing, the program provider

must submit an application for VOL access. Once a program provider has access to VOL he

or she can request a digital certificate. Once obtained, the program provider must install

this certificate in the server that will be sending web services calls to Visa.

Digital certificate from the Visa Certificate Authority (VICA)

Once a program provider has been granted access to VOL they will be able to download

the digital certificate from VICA via VOL email to their server. This certificate must be

downloaded and installed prior to initiating web service or SFTP calls to Visa. Visa requires

a digital certificate for mutual SSL connectivity as part of its secure API service connectivity

requirements.

Security

The security of a cardholder’s Personal Account Number (PAN) along with any and all

Personally Identifiable Identification (PII) is of utmost importance to Visa. Accordingly, Visa

Visa Hosted Enrollment



requires a full security assessment for all program providers. Included in the requirements

is penetration testing. Visa requires partners to undergo penetration testing prior to

making a server to server connection with any outside entity, including any program

provider participating in a Visa Offers Program.

See Section 2 - Security Requirements of this guide for full details.

QA and UAT of the Enrollment Web Services Implementation

- QA (Quality Assurance)

Once a BID has been obtained and VOL access has been established the program provider

can download the digital certificate from VOL, Visa can establish a QA environment to

begin testing the connectivity between our servers. Visa and the program provider will test

all enrollment variations to ensure we have received the fully formed inbound endpoint

message from the program provider. These include:

Enroll: Exclusively for initial enrollment of a cardholder into the program

SaveCard: Add card to an existing user profile

DeleteCard: Remove card from an existing profile. No changes are made to the

user profile.

Unenroll: To completely remove a user profile including all the cards associated

with the profile from the program

Upon successful completion of the secure web service or SFTP batch API calls above, the

program will have passed initial QA of the web services integration.

Note: To the extent that program provider is also receiving inbound endpoint messages

from Visa with authorization and/or clearing transaction information, this will also be

tested as part of the same QA process.

- UAT (User Acceptance Testing)

Please note that in order to proceed with production UAT, a fully signed contract and

acceptance of penetration testing by Visa Global Information Security are required.

Upon completion of successful testing in the QA environment Visa will establish a

production environment for the program.

Testing of enrollment creation and unenrollment will again be executed in order to validate

full functionality.

As with QA, all applicable outbound transaction endpoints from Visa to the program

provider are also tested during this phase.

- Once the program has completed UAT in a production environment and has been accepted as

fully functioning by the program provider, the program can go live to consumers.

5.3 Visa Hosted Enrollment

For program providers who are not PCI compliant or otherwise prefer to have Visa collect the PAN

directly from the consumer, an enrollment form hosted in a secure Visa environment is available.

Consumer Enrollment



When electing this option, Visa will create an enrollment form to collect the cardholder’s PAN, PAN

expiration date and billing zip code along with additional data elements to be mutually agreed upon

and recorded in the technical specification document.

Enrollment Flow Options

- Existing enrollees: For existing program enrollees, the program provider will invite users to link

their Visa card(s) to their account. Typically this would include a marketing landing page

describing the card linked program with a call to action to proceed to the Visa-hosted

enrollment page. Program providers can invite enrollees via an email announcement or any

other available marketing channels.

- New enrollees: For new enrollees in the program, the program provider can integrate the card-

linking process into their overall enrollment flow. When the enrollee has provided their other

required information to the program provider and is ready to connect their Visa card, the

program provider will present a call to action that will link out to the Visa-hosted card

enrollment site. Upon completion of the card enrollment form and successful validation of the

card via an AVS check by Visa, the enrollee can be redirected back to the program provider’s

site. Or, if preferred, the card linking can be the final step in the enrollment process and Visa

will host an enrollment success/completion page.

Enrollment Form Elements

- Branding: The Visa-hosted enrollment form is based on a template that allows the program

provider to customize with their brand assets.

Desktop enrollment site: The program provider can provide a header image with logo and

any other desired branding.

Mobile enrollment site: The program provider can provide a logo image for incorporation

into the mobile enrollment form.

- Data Fields:

At a minimum Visa needs to collect the following fields:

o PAN

o Billing Zip Code (for AVS check)

o PAN Expiration Date (for AVS check)

CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart)

– all enrollees must complete a CAPTCHA field before they can submit enrollment

Additional data fields that may be required depending on the program design include:

o First and Last Name

o External/program provider user ID

o Promo code

o Email address (if email will be used for consumer messaging)

o Mobile number (if SMS will be used for consumer messaging)

o Mobile challenge: required to validate mobile number if collected as a data field

Visa Hosted Enrollment



Cardholder consent: The Visa-hosted enrollment form will generally include the following

legal disclosures depending on the program. All must be accepted by the cardholder

during the enrollment process, and terms must be reviewed and approved by Visa’s legal

department. The program may not launch until Visa legal has approved all of the legal

content on the enrollment form. Program provider remains responsible for cardholder

enrollment. For example only:

o Program terms and conditions – the detailed terms and conditions for the program that

describe the nature of the program and how their information will be used to administer

the program. May include consent to send email to the cardholder if this channel will be

used for consumer messaging.

o Privacy policy – A description of the data collected under the program and how Visa and

the program provider will use that data.

o SMS Consent – In the event that Visa will be collecting a mobile number for use in

communicating with the cardholder, affirmative consent to send SMS communications is

required.

o Please note that any legal content on the page will have a checkbox for the enrollee to

consent to the related terms. All checkboxes are unchecked by default and the enrollee

must check them in order to successfully complete enrollment. Any unchecked box will

result in a failed enrollment.

Use of a query string in conjunction with the Visa-hosted enrollment form

- To simplify the enrollment process, a program provider can choose to utilize an encrypted

query string to pass certain enrollee data fields to Visa at the beginning of the card linked

enrollment process. Visa provides a query string interface that allows the program provider to

pre-set many fields on the enrollment page, using query string variables in the inbound https

page request. This can include information to be passed in the background, such as a program

provider’s internal tracking number for an enrollee, or to prefill data fields on the enrollment

form such as first and last name, email address, mobile number, or a consumer-facing user id.

- Typical scenarios when a query string might be used are:

o When a consumer is logged into the program provider’s website and sees a call to action

to enroll in the card linked program

o When a consumer receives an email from the program provider to enroll in the card

linked program and the email has been pre-coded with specific enrollee data

- When a query string is used, the call to action must inform the enrollee that the program

provider will be passing data to Visa to simplify enrollment.

- The enrollee’s PAN cannot be passed via the query string. This must always be directly

collected by Visa.

- If required, the program provider may choose to digitally sign the EUID (enrollee’s unique Visa

identifier) based on the program provider’s GUID (program provider’s unique user ID). This will

utilize a combination of the program provider’s GUID, Visa-supplied passphrase, and a data

field which has been transmitted to Visa by the program provider and verified by the enrollee

Consumer Enrollment



(such as mobile number or last name) which will then utilize the SHA-256 hashing algorithm to

append a hash to the query string. Please note that when this digital signing technique is used

for a query string, enrollment cannot proceed if the hash is absent, so both the query string

and hashing become a requirement for enrolling in the program. More details on this process

will be available in the technical specifications document for the program, if applicable.

Enrollment reporting from Visa to program provider: When Visa hosts card enrollment under the

program, Visa can provide enrollment data via one of two methods –an outbound enrollment API

call from Visa to the program provider or daily batch reporting via SFTP server

- Enrollment API call from Visa to program provider

Visa can send endpoint messages in real time to the program provider via a series of web

services calls as follows:

o Enroll: Exclusively for initial enrollment of a cardholder into the program

o Unenroll: To completely remove a cardholder from the program

If use of an API is solely outbound from Visa to the program provider with no inbound API

call, full penetration testing may not be required, subject to approval by Visa Global

Information Security.

The data fields to be shared from Visa to the program provider will be mutually agreed

upon and recorded in the technical specifications document, but will not include the full

cardholder PAN. It may include the last four digits of the PAN for enrollee identification

and will include another unique card identifier assigned by Visa, along with any other

agreed upon user and card identifiers.

The process for establishing credentials, testing connectivity and completing QA and UAT

is virtually identical to that described in Section 2 - Security Requirements except it will

strictly be testing outbound receipt of EPM’s from Visa to the program provider instead of

inbound from the program provider to Visa.

Daily batch reporting of enrollment data from Visa to program provider

o If preferred, enrollment may be reported via daily batch reporting via SFTP rather than

the enrollment API

o The data fields to be shared from Visa to the program provider will be mutually agreed

upon and recorded in the technical specifications document, but will not include the full

cardholder PAN. It may include the last four digits of the PAN for enrollee identification

and will include another unique card identifier assigned by Visa, along with any other

agreed upon user and card identifiers.

o This option would require an SFTP connection via Visa’s SFTP provider, GlobalScape. Use

of SFTP requires a security assessment process which may include penetration testing

subject to review by Visa Global Information Security.

Enrollment Marketing

Overview



- All consumer-facing marketing materials to promote program enrollment are subject to review

and approval by Visa’s marketing and legal departments. Approval by Visa marketing and legal

is required prior to program provider’s distribution of these materials.

- Examples of materials subject to review include email invitations to enroll, the program landing

page, banner ads, social media messaging, in-store messaging, radio ads and printed

materials. Please note that this list is not exhaustive and is provided for illustrative purposes

only. Any and all consumer marketing messaging is subject to review and approval.

6 Merchant Onboarding and Offer Setup

6.1 Overview

Before the Visa Offers platform begins tracking and sending transaction information for enrolled

cards, two critical tasks must be completed:

Onboarding of merchants to the program provider’s Visa Offers Platform community and

Creation, approval and publishing of offers via the Visa Client Services Center (CSC) or APIs.

6.2 Visa Offers Platform Client Services Center (CSC)

The Visa Offers Platform Client Services Center is a web portal that enables program providers to:

Create, configure and approve marketing triggers and offers

View archived marketing triggers and offers

Configure notifications

Visa administers user access and approval authority within the Client Services Center and will provide

training prior to program launch.

Sections 6.3 through 6.5 provide detailed information on the merchant onboarding and offer setup

processes. The Visa Implementation Team or account manager for each program will provide training

on the use of the CSC for merchant onboarding, offer creation and offer approval prior to launch.

6.3 Merchant Identification and Onboarding (small and mid-size

businesses)

The Visa Offers Platform utilizes two ID numbers to identify each merchant location: a VMID (Visa

Merchant ID) and a VSID (Visa Store ID). Locating a merchant in Visa’s database is required before the

Merchant Onboarding and Offer Setup



merchant can be onboarded. Once a merchant’s VMID and VSID have been identified it is ready to be

onboarded to the program provider’s community.

There are two primary methods to search for a merchant:

Find Merchants by Transaction: This function can be accessed either from the CSC or via a web

service API call. This is the most reliable to way to find a merchant. The program provider must first

enroll a Visa card via one of the methods described in Section 5.3-Visa Hosted Enrollment and

subsequently make a transaction at a merchant to be onboarded to the program provider’s

community. After 24-48 hours, the program provider will search for the transaction details

(entered on the UI via CSC or provided with the web service API call), which will facilitate

onboarding of the merchant to their community.

To enroll a card for merchant search and onboarding purposes, visit the following URL

https://rtm.visa.com/ExpressEnroll/partneronboarding/Enroll/Landing. Only Visa cards may be

enrolled. Please note that many gift and pre-paid card transactions are not routed through

VisaNet, so beware that results may not be consistent when this type of card type is enrolled.

Required fields for enrollment include First and Last Names, 16-digit PAN (Personal Account

Number), email address, and a program provider ID that corresponds to the program.

After enrolling a card via the onboarding website, the program provider must make transactions

with a minimum amount of $1.00 at merchants to be onboarded to the program’s community.

Transactions of less than $1.00 are often processed differently and so may not be tracked

individually in the VisaNet data. Because the search will be based on specific transactions, please

ensure that all transaction amounts made on the same card are unique within a 3 day/72 hour

period. The program provider should create a log of all transactions including the merchant name,

address, transaction date and amount, and the card used (PAN last 4 and email address used to

enroll via the Partner Onboarding).

After transactions have been made at relevant merchants with the enrolled card, the program

provider must search for the transactions by either making a SearchMerchantDetailsByTransaction

web services API call or using the Visa Client Services Center web portal (under the Merchant Tab).

When the relevant merchant has been located, the merchant can be added to the program

provider’s community by making an OnboardMerchant web services API call. If the merchant has

been located via the Visa CSC, there is be an option to onboard the merchant directly from the

search result.

Merchant onboarding utilizing the transaction matching process typically takes about one week to

complete.

Find Merchants by Attributes

Merchants may also sometimes be identified via their Attributes like

- Acquirer Merchant ID (MID) - This type of search is performed utilizing the merchant name,

address, and MID. The match rate is in the 20-50% range. Similar to finding merchants by

transaction, a search by MID and address can be done by making either a web services API call

or by using the CSC web portal.

https://rtm.visa.com/ExpressEnroll/partneronboarding/Enroll/Landing

Merchant Onboarding (for large businesses)



- Business Identification Number (BIN) and Card Acceptor ID (CAID)

This type of search is performed utilizing the BIN/CAID combination along with merchant

name and address. The match rate is in the 20-50% range. Similar to finding merchants by

transaction, a search by BIN/CAID and address can be done by making either a web services

API call or by using the CSC web portal.

- Merchant name and address

This type of search is performed utilizing merchant name and address. The match rate is in the

20-50% range. Similar to finding merchants by transaction, a search by merchant name and

address can be done by making either a web services API call or by using the CSC web portal.

SearchMerchant

This operation was introduced in version 6. It provides the capability to search for merchants by

means of the following attributes:

- VisaFranchiseId

- VisaFranchiseName

- VisaEnterpriseId

- VisaEnterpriseName

- VisaMerchantId

- VisaMerchantName

- VisaStoreId

- VisaStoreName

This API provides an additional means of looking up merchants for the purpose of including them

in a community.

6.4 Merchant Onboarding (for large businesses)

For versions before VOP version 6 onboarding a merchant required a swipe at each individual location.

While this may not have been an issue for small or mid-size businesses, the process of swiping at

every location for a large regional or national enterprise was not feasible. For partners using V5 or

earlier Visa has to establish special rules to identify individual merchants belonging to a large regional

or national enterprise. Under the normal V5 and earlier process, program providers must work with

their Visa Account Manager to onboard large numbers of individual merchants. It takes two to four

weeks to locate and onboard a large regional or national enterprise successfully, so please plan

accordingly for partners still using V5 or earlier.

Starting with version 6 program providers can use the new “SearchMerchant” Web service operation

to search for and onboard targeted merchants on their own. The interface provides searches with

wildcards to return large numbers of merchants from which a partner can select merchants to

onboard.

Merchant Onboarding and Offer Setup



6.5 Offer Setup and Publishing

After a merchant has been onboarded to the program provider’s community, the program provider

will be able to set up offers. The program provider can do this either in the CSC or via the offer

creation API (See Section 3.3.3-Offer APIs). In the CSC, an ‘offer’ is a set of ‘events.’ If the event

conditions are satisfied the VOP will execute an ‘action’. An example of an action is an “end point

message or “EPM.” An EPM notifies a program provider that a cardholder has satisfied the conditions

for an offer have been satisfied. The program provider can at that time complete the offer delivery

steps for the cardholder.

After offers have been configured the Visa Offers Platform tracks and sends transaction information to

the program provider. The conditions for an offer do not necessarily need to match to the promotion

in place with merchant partners.

Some primary attributes that can be used in the offer set up include:

Merchant Name

Merchant State

Merchant Zip

Minimum Transaction Amount

Offer Start and End Date

A Visa Account Manager will assist in creating offer template(s) for use when creating offers. A sample

use case for a template would be one that has two events: one event whose action is to send an

endpoint message in real time when an authorization occurs at a specific merchant location and a

second event whose action is to send an endpoint message when the transaction settles at the bank.

The fields to be included with each event may also be configured within a template.

The program provider manages offer creation and approval. Once offer creation and approval is

complete, the program provider must notify their designated Visa Account Manager that the offer is

ready for review and publishing. Program providers will also need to include an Offer Matrix

document whenever there are new offers for publishing by Visa. Visa will provide an Offer Matrix

spreadsheet template to the program provider during the implementation process.

Visa Account Management uses this document to track all offers entered into the CSC and ensures

that what has been entered matches the offer’s parameters.

The standard turnaround time for publishing offers is 2 business days, but can take longer depending

on the volume of offers to be published and the complexity of those offers. An offer must be

published by Visa before the Visa Offers platform will start tracking and sending transaction details.

Billing



7 Administrative Requirements

There are a number of administrative tasks required to facilitate billing, reporting, and file transfers. A

brief description of each is provided in this section.

7.1 Billing

Detailed billing information is available from the Visa Implementation team in a separate document

called the “Getting Started Billing Guide.” Here are the key activities required to establish billing and

payment processes.

Establish a Visa Business ID (BID) through submission of BID Request Form

- Required for billing

- May take up to 14 calendar days to obtain

Complete Automated Clearing House (ACH) Form

- Payment to Visa is made exclusively via ACH, so this is a requirement for each implementation

Enroll in Visa Online (VOL) to access monthly invoices

- All billing for the program is done electronically, so each partner must enroll in VOL in order to

access invoices

- Once enrolled in VOL, the partner must submit an additional form to gain access to the Online

Merchant Invoice tool (OMI)

Billing Cycle – Timing

- First bill for services will be issued approximately 30 days after the program start date

- Subsequent bills are invoiced monthly

7.2 Reporting

During the implementation solution design phase the partner and Visa will determine what, if any,

standardized batch reporting is required to support the program. Reports will be sent via either secure

email or Secure File Transfer Protocol (SFTP).

7.3 Secure File Transfer Protocol (SFTP) Setup

Visa’s preferred method for transmitting batch reporting is via SFTP. As such we recommend

establishing SFTP connectivity between Visa and the program provider for each program. The Visa

program Implementation Manager will coordinate data exchange and testing for SFTP. Visa utilizes

Marketing and Legal Reviews of Consumer-Facing Content



GlobalScape technology for its SFTP service. Some key requirements for program provider SFTP setup

are as follows:

Security Assessment: The use of SFTP must be included in the overall security review documented

in Section 2 - Security Requirements above. Additionally, Visa’s security analyst will need to review

the program provider’s SFTP server architecture/data flow and will request details on recent

penetration/vulnerability assessment specific to the SFTP environment.

Inbound vs. Outbound: Visa can support distribution of files via either a “push” of files from Visa to

the program provider or “pull” from the program provider to Visa. This will be defined during the

implementation phase.

Public keys: Visa will provide public keys to a program provider for download to their SFTP

environment. A separate key is required for each drop off directory.

Configuration variables/information to be provided by the program provider

- IP Address and ports for files inbound from Visa

- Authentication Method

- Drop off directories for files (separate directories are required for QA and Production)

- SFTP user ID’s: A separate ID must be provided for each drop off directory and each of the

public keys provided by Visa will be associated with an ID by the program provider.

Testing

- After all of the steps above have been completed, Visa and the program provider will have a

working session to test SFTP connectivity in a QA environment, and make adjustments as

needed.

- Once QA testing has been completed, Visa and the program provider will have another

working session to test the SFTP in production.

- Once production testing is successful, reporting will start being sent by SFTP on a date

mutually agreed upon by Visa and program provider.

Please note that production testing cannot be done until the SFTP portion of the security assessment

has been completed. Initial testing in QA is permitted.

8 Marketing and Legal Reviews of Consumer-Facing Content

8.1 Overview

All consumer-facing content that references the Visa name or brand mark must be reviewed and

approved by the Visa marketing and legal departments prior to publishing/distribution. The program

provider should send the materials to their Visa implementation or Account Manager (depending on

program stage) at least ten (10) business days in advance of the intended distribution date. The Visa

contact will then route the materials internally and return feedback to the program provider. This

Implementation/Pre-Launch Reviews



feedback may include recommended edits, so it is critical to provide ample time in the event that

additional review cycles are required. Notwithstanding any Visa review/approval, program provider

remains solely responsible for the Program, including without limitation as to cardholder enrollment,

participating merchants, offer content etc.

8.2 Implementation/Pre-Launch Reviews

The pre-launch period tends to have the heaviest load of documents/promotional materials for review

by Visa marketing and legal. During this period the Visa Implementation Manager will coordinate all

reviews. While these may vary by implementation, common examples include:

Consumer enrollment legal consents – as detailed in Section 5.3 - Visa Hosted Enrollment, Visa

legal must review the program provider’s terms and conditions, privacy policy, and SMS consent

language (if applicable). This applies for enrollment via a secure API or via a Visa-hosted

enrollment form.

Enrollment marketing materials – as detailed in Section 5.3 - Visa Hosted Enrollment, all consumer-

facing marketing materials to promote program enrollment are subject to review and approval by

Visa’s marketing and legal departments. Examples of materials subject to review include email

invitations to enroll, the program landing page, banner ads, social media messaging, in-store

messaging, radio ads and printed materials. Please note that this list is not exhaustive and is

provided for illustrative purposes only. Any and all consumer marketing messaging is subject to

review and approval.

8.3 Ongoing/Post-Launch Reviews

Once the program has launched, Visa marketing and legal must still review any consumer-facing

materials that relate to the Visa service or reference the Visa name or brand. During this period the Visa

Account Manager will coordinate all reviews. While these may vary by program, examples include:

Enrollment marketing materials – as in Section 5.3 - Visa Hosted Enrollment, all consumer-facing

marketing materials to promote program enrollment are subject to review and approval by Visa’s

marketing and legal departments.

Service messages, program updates, award status, etc. – any communication with program

enrollees that includes the Visa name or brand must be reviewed in advance of distribution. This

includes service emails, point awards or any other program update. To the extent that such

message are based on a template that will be used for a set period of time, the template need only

be reviewed and approved by Visa once. However any changes to said template would require a

fresh review and approval by Visa.

If the program provider has any doubt as to whether consumer-facing materials need to be

reviewed by Visa prior to distribution, it is best to err on the side of caution and send the content

to your Visa Account Manager for assessment.

Transition to Account Management



9 Transition to Account Management

9.1 Overview

Once the program has been fully launched, a dedicated Visa Account Manager will be the day to day

contact for the program provider. The Visa Account Manager will guide the program provider through

post-launch merchant and offer onboarding, billing, reporting and any other business-as-usual needs.

While the Implementation Manager will be the primary contact throughout the launch phase of the

program, the Visa Account Manager will become involved during the UAT/testing phase of the

program implementation to ensure a seamless transition post-launch. After program launch, the Visa

Account Manager will take the lead on the day to day operations and issues management and the

Visa Implementation Manager will continue to serve as a resource as long as they are needed during

the initial critical care period.

The Visa Account Manager will also serve as a consultant for the program provider, working with them

to understand program goals and providing the entrée to any resources at Visa to help meet those

goals. Finally, the Visa Account Manager will work with the program provider to understand any

program or platform enhancement needs for assessment by Visa’s product team and to shape future

roadmap planning.

9.2 BAU Operations

The Visa Account Manager will be the day-to-day for business-as-usual operations for the program.

The Visa Account Manager will assist you with:

Merchant and offer onboarding troubleshooting

Offer publishing as needed

Questions or concerns with CSC

Monthly billing and invoicing

Reporting needs as established during the implementation phase

The Visa Account Manager will facilitate regular meetings and status tracking documentation to

manage BAU Operations, including weekly status sheets, merchant and offer matrixes, and invoices.

9.3 Issues Management

The Visa Account Manager will be the resource for issues management and mitigation. The Visa

Account Manager will assist with:

Consultation



Issue research

Issue diagnosis

Issue resolution

The Visa Account Manager will provide the program provider with a clear escalation path and severity

classification to facilitate issues resolution.

9.4 Consultation

The Visa Account Manager will consult with the program provider during the launch phase and

throughout the life of the program to understand objectives and goals. Working together, the Visa

Account Manager and the program provider will jointly identify opportunities to meet or exceed

program goals. The Visa Account Manager can also provide entrée to other Visa Resources such as

data analytics and marketing. Finally, the Visa Account Manager will work with the program provider

to identify potential enhancement opportunities for the program and platform.

Consultation


August 2015 29

Glossary

A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Term Definition

A

Account Range An account range will defines a slice of an entire BIN. It is a logical

grouping of card account numbers. Members of an account range

share the first 10 digits of their card account number.

ACH Complete Automated Clearing House. Payment to Visa is made

exclusively via ACH.

Acquirer

A bank that processes and settles a merchant's daily credit card

transactions, and then in turn settles those transactions with the card

issuer. Merchants must maintain such an account to receive credit for

credit card transactions. Daily card transaction totals are deposited in

the merchant's account after settlement and discount fees are

deducted. In this way, an acquirer serves as the intermediary, to

facilitate the credit transaction and pay the merchant.

Action

An event may have many actions, up to a maximum of one per channel.

Sending an EPM message for an event is an example of an “action.”

B

Basic Authentication A required component in VOP web service client authentication. Must

contain Visa supplied credentials.

BAU Business As Usual

BID—Business Identification A unique number assigned to any business entity that has a

relationship with Visa. This number is maintained by the Franchise

Management group. Any Visa Offers Platform organization may have at

least one BID. Many-to-one relationship to a partner.

C

Campaign Group of related offers for a partner’s community.

Card Product A category of payment instrument that defines procedures, rules, and

options/features, such as credit, debit, charge, or prepaid.

Card Type Distinguishes between the types of cards offered (credit card, debit

card, commercial card, etc.)

Cardholder An individual who possesses a Visa card product.

Glossary



Term Definition

Cardholder Information Security

Program (CISP)

Mandated since June 2001, the Cardholder Information Security

Program is intended to protect Visa cardholder data—wherever it

resides—ensuring that issuers, merchants, and service providers

maintain the highest information security standards.

Campaign A many-to-one relationship to a community. A partner may establish a

campaign at any one of the three community levels, i.e. community,

community group or community client.

Card Last-4 A candidate list of four-digit numbers from which a user must identify

one that matches the last four digits of one of his or her enrolled cards.

CAPTCHA “Completely Automated Public Turing test to tell Computers and

Humans Apart” Used in Express Enrollment

Channel Means by which a partner communicates with an enrollee. Examples

include:

Email “

SMS (Text message)

Facebook

CISP Cardholder Information Security Program

Clearing During the clearing process the acquirer provides the appropriate

issuer with information on the sale. No money is exchange during

clearing. Clearing involves the exchange of data only. The acquirer

provides data required to identify the cardholder’s account and provide

the dollar amount of the sales. When the issuing bank gets this data,

the bank posts the amount of the sale as a draw against the

cardholder’s available credit and prepares to send payment to the

acquirer.

Community Client A many-to-one relationship to a community group. A sub-grouping

below a community group.

Community Group A many-to-one relationship to a campaign. A sub-grouping below a

community.

Community Collection of partner enrollees. Many-to-one relationship to a

community group. Can be identified on one of three levels:

Community

Community Group

Community Client

Contact Type An attribute associated to each Visa Offers Platform person contact,

and each person contact can be associated to one or more attributes.

Contact types include email, text, telephone, …

Consultation


August 2015 31

Term Definition

Contacts Organizations or Persons that are maintained within Visa Offers

Platform

CSA Customer Service Associate

CSC Client Service Center – The administrative interface that manages

communities.

D

DSS Personal Card Industry Data Security Standard

(http://usa.visa.com/download/merchants/cisp_overview.pdf)

E

End Point Message A message delivered to a partner by VOP. Endpoint messages may be

formatted in SOAP, JSON, or straight XML based on the partner’s

preference.

Envelope The outermost wrapper for a SOAP payload.

Event Many-to-one relationship to an offer. A real-time action by an enrollee

that meets some predefined criteria. Examples include:

Enrollee activates an offer presented to the enrollee by a

partner.

Enrollee makes a card swipe satisfying the conditions of the

offer.

Express Enrollment A Visa-provided GUI to enroll cardholders into a community.

F

Fulfillment The awarding of an offer’s benefits to an enrollee.

G

GCAS

Global Customer Assistance Service—A suite of services offered to all Visa issuers worldwide by the VCCS & its service partners.

GlobalScape Visa’s SFTP provider

GUID Global User ID

GMT - Greenwich Mean Time The date and time standard used by Visa systems.

GMR Global Merchant Repository

H

I

http://usa.visa.com/download/merchants/cisp_overview.pdf

Glossary



Term Definition

Identity Provider Identifies the organization that maintains a community’s credentials

store.

Issuer Any association member financial institution, bank, credit union or

company that issues, or causes to be issued, Visa cards to cardholders

J

JSON JavaScript Object Notation. A formatting option for an end point

message.

K

L

M

MCC A Merchant Category Code is a four-digit number assigned to a

business by MasterCard or VISA when the business first starts

accepting one of these cards as a form of payment. The MCC is used to

classify the business by the type of goods or services it provides. In the

US it can be used to determine if a payment needs to be reported to

the IRS for tax purposes.

MSA In the United States a Metropolitan Statistical Area (MSA) is a

geographical region with a relatively high population density at its core

and close economic ties throughout the area.

Mutual SSL Authentication A scheme in which both parties in the SSL handshake provide their

public keys to the other. See

http://www.codeproject.com/Articles/326574/An-Introduction-to-

Mutual-SSL-Authentication.

N

Notification Many-to-one relationship to an offer. Enrollee is informed of having

satisfied the conditions of an offer and is presented with the means of

obtaining its benefits.

Notification Channel "The means by which an enrollee is informed of having satisfied an

offer. Examples include:

Text message or “SMS”

Email

Facebook

http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

http://www.codeproject.com/Articles/326574/An-Introduction-to-Mutual-SSL-Authentication

Consultation


August 2015 33

Term Definition

O

Offer Many-to-one relationship to a Campaign. An opportunity to receive a

benefit for a targeted enrollee. Fulfillment contingent on a set of

conditions. Transactions meeting the conditions trigger events.

OMI Online Merchant Invoice tool.

P

PAI Personal Account Information. According to Visa’s key controls any

person or organization that has access to personal information must

observe specific security practices to maintain the privacy and security

of the entrusted information. In the case of a partner Visa requires the

organization to be certified as PCI compliant.

Pen Test Penetration Testing. Extensive test to identify potential vulnerabilities

to hacking in partner software systems.

PAN Personal Account Number

PCI Data Security Standards The Payment Card Industry Data Security Standard (PCI DSS) is an

information security standard for organizations that handle cardholder

information for the major debit, credit, prepaid, e-purse, ATM, and POS

cards. (http://usa.visa.com/download/merchants/cisp_overview.pdf)

PII Personally Identifiable Information

Q

QA A test environment provided by Visa to allow partners to validate their

client software.

R

REST Representational State Transfer is a style of software architecture for

implementing Web based applications. Used in “Express Enrollment.”

RPIN The rewards program identification number of an issuer’s portfolio as

maintained in the Rewards Program Manager (RPM) Application.

S

Sandbox A preliminary test environment that allows new partners to become

familiar with the VOP connectivity requirements.

Segment A database query run nightly to select a target group of enrollees.

Settlement The second step is the actual exchange of funds. The issuer sends a

record of money that is being transferred from its account to that of

the acquirer. From this account the acquirer pays the merchant. Funds

are settled between issuers and acquirers through accounts with large

http://usa.visa.com/download/merchants/cisp_overview.pdf

Glossary



Term Definition

banks that are members of the Federal Reserve System and have been

selected for that purpose. Payments to merchants are made usually

through the Federal Reserve’s Automated Clearing House (the “ACH”)

which is an electronic funds transfer system.

SFTP Secure File Transfer Protocol

SOAP A protocol specification for exchanging structured information in the

implementation of a Web Service.

SMS Short Message Service is a text messaging service component of

phone, Web, or mobile communication systems.

SoapUI Community version of SmartBear’s SOAP Web Service testing tool.

Obtain at http://www.soapui.org/downloads/soapui/open-source.html

SSL Secure Socket Layer. Replaced by TLS.

T

Tag A database query to identify (“tag”) a target group of enrollees. Tag

queries are run on demand. Can be promoted to a “segment.”

Tag Group A higher level grouping of related tags. Examples include Affinities,

Contact Preference, and Enrollment mode.

TLS 1.2 Transport Layer Security. Replaced Secure Socket Layer (SSL). TLS 1.2 is

the most current (ca. 2015) version. Clients must be able to run TLS 1.2

to connect with VOP.

U

UAT User Acceptance Testing

V

VCCS Visa Call Center Services or Visa Customer Care Services

VDC Visa Development Center (https://developer.visa.com/vop)

VICA Visa Certificate Authority. Issues the X.509 SSL certificates required to

connect to VOP servers.

VIS – Visa Information System Visa’s corporate repository for Partner and non-Partner legal and

contractual information, including:

Visa An organization type in Visa Offers Platform that is used to define the

organization as part of the Visa Company, which would apply to ALL

issuers in Visa Offers Platform.

Visa Offers Platform The centralized system that manages real-time marketing information.

Visa Incentive Network (VIN) A robust platform designed to assist issuers in distributing rewards to

cardholders in the form of merchant and category-wide offers; a core

http://www.soapui.org/downloads/soapui/open-source.html


Consultation


August 2015 35

Term Definition

eligibility requirement for issuers of both Visa Signature and Visa

Traditional Rewards.

Visa Online (VOL) Visa’s system for controlling partner access to Visa’s online systems.

VMID Visa Merchant ID

VOL Visa Online

VOP Visa Offers Platform

VSID Visa Store ID

W

WSDL Web Service Definition Language, a platform independent means of

defining Web service application programming interfaces. The current

and currently supported versions of the VOP public APIs are available

from the Visa Development Center (VDC) at

https://developer.visa.com/vop.

X

XML Extensible Markup Language is a markup language that defines a set of

rules for encoding documents in a format

Y

Z


Consultation

