MasterCard SecureCode SMI Manual Merchant

2015-01-11

: Mc Smi Manualmerchant SMI_ManualMerchant

Open the PDF directly: View PDF .
Page Count: 72

MasterCard SecureCode—Merchant Implementation Guide
Notices
Summary of Changes
- Summary of Changes, 17 June 2014
- Summary of Changes, 3 January 2014
Table of Contents
Chapter 1 SecureCode Merchant Implementation Overview
Chapter 2 3-D Secure Solution
Chapter 3 Merchants
Appendix A Merchant Customer Service Guide
Appendix B MasterCard SecureCode SPA Algorithm Specifications
- AAV Layout
- Base64 Encoding
  - Base64 Encoding Examples
  - Base64 Alphabet
Appendix C MasterCard SecureCode Contact Information
- MasterCard SecureCode Contact Information
Appendix D Maestro Processing Considerations
- Account in Good Standing
Appendix E India IVR Transations (SecureTelephone)
Appendix F MasterCard Advance Registration Program Requirements
Appendix G MasterCard Extensions for the Brazil Market
- Brazil Market Extensions

MasterCardSecureCode

MerchantImplementationGuide

17June2014

Notices

Followingarepoliciespertainingtoproprietaryrights,trademarks,translations,anddetailsabout

theavailabilityofadditionalinformationonline.

ProprietaryRights

TheinformationcontainedinthisdocumentisproprietaryandconfidentialtoMasterCardInternational

Incorporated,oneormoreofitsaffiliatedentities(collectively“MasterCard”),orboth.

Thismaterialmaynotbeduplicated,published,ordisclosed,inwholeorinpart,withouttheprior

writtenpermissionofMasterCard.

Trademarks

TrademarknoticesandsymbolsusedinthisdocumentreflecttheregistrationstatusofMasterCard

trademarksintheUnitedStates.PleaseconsultwiththeCustomerOperationsServicesteamorthe

MasterCardLawDepartmentfortheregistrationstatusofparticularproduct,program,orservicenames

outsidetheUnitedStates.

Allthird-partyproductandservicenamesaretrademarksorregisteredtrademarksoftheirrespective

owners.

Disclaimer

MasterCardmakesnorepresentationsorwarrantiesofanykind,expressorimplied,withrespectto

thecontentsofthisdocument.Withoutlimitation,MasterCardspecificallydisclaimsallrepresentations

andwarrantieswithrespecttothisdocumentandanyintellectualpropertyrightssubsistingthereinor

anypartthereof,includingbutnotlimitedtoanyandallimpliedwarrantiesoftitle,non-infringement,

orsuitabilityforanypurpose(whetherornotMasterCardhasbeenadvised,hasreasontoknow,oris

otherwiseinfactawareofanyinformation)orachievementofanyparticularresult.Withoutlimitation,

MasterCardspecificallydisclaimsallrepresentationsandwarrantiesthatanypracticeorimplementationof

thisdocumentwillnotinfringeanythirdpartypatents,copyrights,tradesecretsorotherrights.

Translation

AtranslationofanyMasterCardmanual,bulletin,release,orotherMasterCarddocumentintoalanguage

otherthanEnglishisintendedsolelyasaconveniencetoMasterCardcustomers.MasterCardprovidesany

translateddocumenttoitscustomers“ASIS”andmakesnorepresentationsorwarrantiesofanykind

withrespecttothetranslateddocument,including,butnotlimitedto,itsaccuracyorreliability.Inno

eventshallMasterCardbeliableforanydamagesresultingfromrelianceonanytranslateddocument.

TheEnglishversionofanyMasterCarddocumentwilltakeprecedenceoveranytranslatedversionin

anylegalproceeding.

InformationAvailableOnline

MasterCardprovidesdetailsaboutthestandardsusedforthisdocument—includingtimesexpressed,

languageuse,andcontactinformation—onthePublicationsSupportpageavailableonMasterCard

Connect™.GotoPublicationsSupportforcentralizedinformation.

SMI17June2014•MasterCardSecureCode—MerchantImplementationGuide

SummaryofChanges,17June2014

Thisdocumentreflectschangeseffectivesincethelastpublicationofthismanual.

DescriptionofChangeWheretoLook

AddednotesindicatingthatboththeMasterCardAdvanceRegistration

ProgramandMaestroAdvanceRegistrationProgram(MARP)areclosedto

newbusinessandwillbedecommissionedon1June2015.

Throughoutdocument

AddedreferencestotheMasterCardAttemptsProcessingServiceandthe

MasterCardAuthenticationHistoryServer.

Throughoutdocument

AddednewappendixtoprovideanoverviewoftheMasterCard

requirementstosupportIVRTransactionsinIndia.

IndiaIVRTransations

(SecureTelephone)

MasterCardSecureCode—MerchantImplementationGuide•17June20141

SummaryofChanges,3January2014

Thisdocumentreflectschangeseffectivesincethelastpublicationofthismanual.

DescriptionofChangeWheretoLook

UpdatedemailaddressfortheMasterCard®SecureCode™CustomerSupport

Teamtosecurecode_customer_support@mastercard.com.

Throughoutdocument

ReferencestoMaestroGlobalRuleshavebeenremovedand/orreplaced

withreferencestotheMasterCardRulesortheTransactionProcessing

Rules,whicheverapplies.

Throughoutdocument

UpdatedtheCustomerImplementationServicescontactinformationby

region.

UpdatedtheURLoftheMasterCardSecureCodeMerchantFAQsandProgram

IdentifierGuidelines.

MasterCardSecureCode

ContactInformation

AddedcontentabouttheAccountStatusInquiry.AccountinGoodStanding

UpdatedtheMasterCardConnect™pathbywhichcustomersmayaccess

theMasterCardandMaestroAdvanceRegistrationProgramsParticipation

RequestForm(Form0900).

ParticipationRequirements

forMerchants

MasterCardSecureCode—MerchantImplementationGuide•3January20141

TableofContents

Chapter1SecureCodeMerchantImplementationOverview............1-i

MasterCardandE-commerce...................................................................................................1-1

MaestroandE-commerce........................................................................................................1-1

GrowYourOnlineBusiness....................................................................................................1-2

MasterCardSecureCodeProgramPlatform...............................................................................1-3

WhatisUCAFandItsStructure?........................................................................................1-3

WhatisanAAV?.................................................................................................................1-4

WhatisaMerchantPlug-In...............................................................................................1-5

Chapter23-DSecureSolution.............................................................2-i

3-DSecureSolutionOverview.................................................................................................2-1

Components.............................................................................................................................2-1

IssuerDomain....................................................................................................................2-2

AcquirerDomain...............................................................................................................2-3

InteroperabilityDomain.....................................................................................................2-3

3-DSecureSolutionMessageTypes........................................................................................2-5

CardRangeRequest/Response..........................................................................................2-5

VerificationRequest/Response...........................................................................................2-5

PayerAuthenticationRequest/Response............................................................................2-6

PayerAuthenticationTransactionRequest/Response........................................................2-6

CardholderEnrollment.............................................................................................................2-6

CardholderEnrollmentProcess..........................................................................................2-7

CardholderAuthentication.......................................................................................................2-7

SampleCardholderAuthenticationProcess.......................................................................2-7

SampleCardholderAuthenticationFlow.........................................................................2-10

Chapter3Merchants............................................................................3-i

Overview.................................................................................................................................3-1

MerchantInfrastructure............................................................................................................3-1

EstablishmentofMasterCardSecureCodeOperatingEnvironment....................................3-2

AuthorizationSystemMessageEnhancements.........................................................................3-2

PassingtheAA VintheAuthorizationMessage..................................................................3-2

E-CommerceCommerceIndicator.....................................................................................3-3

RecurringPayments...........................................................................................................3-5

MasterCardSecureCode—MerchantImplementationGuide•17June2014i

TableofContents

MaestroConsiderations............................................................................................................3-5

Customization..........................................................................................................................3-6

MasterCardSecureCodeProgramIdentifierUsageGuidelines...........................................3-6

IntegratedSupportforMerchantPlug-InProcessing.........................................................3-6

ConsumerMessageonPaymentPage...............................................................................3-8

CreationofCardholderAuthenticationWindow................................................................3-8

TERMURLField..................................................................................................................3-9

ReplayDetection...............................................................................................................3-9

MerchantServerPlug-InConfiguration............................................................................3-10

Operational............................................................................................................................3-12

LoadingofMasterCardRootCertificates..........................................................................3-12

LoadingofMasterCardSSLClientCertificate...................................................................3-12

MPILogMonitoring.........................................................................................................3-12

MPIAuthenticationRequest/ResponseArchival..............................................................3-13

AAVProcessing......................................................................................................................3-13

GlobalInfrastructureTestingRequirements...........................................................................3-13

MasterCardSiteDataProtectionProgram..............................................................................3-14

MasterCardSecureCodeMerchantProcessandLiabilityShiftMatrix.....................................3-14

AppendixAMerchantCustomerServiceGuide....................................A-i

FrequentlyAskedQuestions....................................................................................................A-1

MasterCardSecureCodeFAQs............................................................................................A-1

CardholderEnrollmentintheMasterCardSecureCodeProgram..............................................A-4

ConsumerBuyingScenarios....................................................................................................A-5

Authentication—Successful................................................................................................A-6

Authentication—ForgottenSecureCode.............................................................................A-7

Authentication—Failed......................................................................................................A-8

ActivationDuringShopping(ADS)....................................................................................A-8

ActivationDuringShopping—OptOutofEnrollment.....................................................A-10

AppendixBMasterCardSecureCodeSPAAlgorithm

Specications............................................................................................B-i

AAVLayout..............................................................................................................................B-1

Base64Encoding.....................................................................................................................B-1

Base64EncodingExamples...............................................................................................B-2

Base64Alphabet................................................................................................................B-2

ii17June2014•MasterCardSecureCode—MerchantImplementationGuide

TableofContents

AppendixCMasterCardSecureCodeContactInformation..................C-i

MasterCardSecureCodeContactInformation...........................................................................C-1

AppendixDMaestroProcessingConsiderations..................................D-i

AccountinGoodStanding......................................................................................................D-1

AppendixEIndiaIVRTransations(SecureTelephone)...........................E-i

Overview.................................................................................................................................E-1

DataExtensionstotheExisting3-DSecureProtocol...............................................................E-1

UCAFTransportinMasterCardAuthorizationMessages..........................................................E-1

MasterCardSecureCode—SecurityLevelIndicator(DE48,subelement42)......................E-2

UniversalCardholderAuthenticationField(DE48,subelement43)..................................E-3

WhatisanAAV?.................................................................................................................E-3

SampleIVRTransactionFlow............................................................................................E-4

MasterCardSecureCodeComplianceandFunctionalTesting............................................E-4

AppendixFMasterCardAdvanceRegistrationProgram

Requirements............................................................................................F-i

MasterCardAdvanceRegistrationProgram..............................................................................F-1

MARPMerchantUseofMasterCardSecureCode......................................................................F-1

IssuerParticipationinMARP....................................................................................................F-2

AppendixGMasterCardExtensionsfortheBrazilMarket..................G-i

BrazilMarketExtensions.........................................................................................................G-1

MasterCardSecureCode—MerchantImplementationGuide•17June2014iii

Chapter1SecureCodeMerchantImplementation

Overview

ThissectionprovidesageneraloverviewoftheMasterCard®SecureCode™Electronic

Commerceprogram.

MasterCardandE-commerce.........................................................................................................1-1

MaestroandE-commerce..............................................................................................................1-1

GrowYourOnlineBusiness..........................................................................................................1-2

MasterCardSecureCodeProgramPlatform.....................................................................................1-3

WhatisUCAFandItsStructure?..............................................................................................1-3

WhatisanAAV?.......................................................................................................................1-4

WhatisaMerchantPlug-In.....................................................................................................1-5

MasterCardSecureCode—MerchantImplementationGuide•17June20141-i

SecureCodeMerchantImplementationOverview

MasterCardandE-commerce

E-commercetransactionsaccountforasignificantandincreasingshareof

MasterCard®grossdollarvolume.

Thenumberofremotetransactionsisincreasingatarateofmorethan40

percentperyearandgrowing.Forthisreason,itisimportanttoposition

e-commerceandmobilecommercechannels—webaccessfromPCs,PDAs,

mobilephones,andotherwireless-enableddevices—toincreasegrossdollar

volumeprofitabilitybyusingsecurityandauthenticationsolutionsthat

authenticatecardholders.Thisreduceschargebacksandexpensesthatare

associatedwithdisputedtransactions.

Fromariskperspective,thecurrentMasterCardelectronicandmobile

transactionenvironmentcloselyresemblestraditionalmailorder/telephone

order(MO/TO)transactions.Theremotenatureofthesetransactionsincreases

risk,resultinginmorecardholderdisputes,andassociatedchargebacks.

Thesefactorsincreasecoststoallpartiesformanagingdisputesand

chargebacks.AccordingtoMasterCarddata,morethan70percentofall

chargebacksfore-commercetransactionsareassociatedwithreasoncode

4837(NoCardholderAuthorization)orreasoncode4863(CardholderNot

Recognized),andarecurrentlyestimatedatacostofUSD34.00perchargeback

totheindustry.Thesereasoncodesareusedwheretheconsumerdenies

responsibilityforthetransactionandtheacquirerlacksevidenceofthe

cardholder’sauthentication,ortheconsumerdoesnotrecognizethetransaction.

Provingthatthecardholderconductedandauthorizedthetransactionina

virtual,non–face-to-faceenvironmentofelectronicandmobilecommerce

hasbeenextremelydifficult.TheMasterCard®SecureCode™programis

designedtoprovidetheinfrastructureforanissuersecuritysolutionthat

reducesproblemsassociatedwithdisputedcharges,offeringtheopportunityto

authenticatethecardholderatthetimeofpurchase.Disputedchargesaffectall

partiesinatransaction—issuer,acquirer,cardholder,andmerchant.

MaestroandE-commerce

Lowcreditcardpenetrationinmanycountrieshasledtotheuseofinefficient

paymentformslikecashondelivery,check,anddomestictransfer/automated

clearinghouse(ACH).

MasterCard®SecureCode™willallowMaestro®cardstobeusedforInternet

purchasesinasafeandsecureenvironment.MasterCardSecureCodeallows

Maestrotobethefirstfully-authenticatedglobaldebitbrandacceptedonthe

Internet.

Unlessotherwisestatedbydomesticcountryrules,allMaestroInternet

transactionsareguaranteed.PleasenotethatamerchantcannotacceptMaestro

transactionsunlesstheysupportMasterCardSecureCode.

MasterCardSecureCode—MerchantImplementationGuide•17June20141-1

SecureCodeMerchantImplementationOverview

GrowYourOnlineBusiness

MasterCard®SecureCode™offersflexible,robust,andeasytoimplement

solutionsforcardholderauthentication.Becauserequirementsvaryfromissuer

toissuer,MasterCardplacesapremiumonflexibility,enablingissuerstochoose

fromabroadarrayofsecuritysolutionsforauthenticatingtheircardholders.

Thesesolutionsincludepassword,EMVchipcard-basedapproaches,orother

solutionsoftheirownchoosing.Issuersshoulddecideontheirauthentication

strategybybalancingtheirviewofriskagainstthecardholderexperience.

AtlaunchofMasterCardSecureCode,a“riskaverse”strategywasvisualized

whereeverymerchanttransactionwouldbepresentedtotheissuerfor

authenticationandtheissuerwouldensurethatthecardholderauthenticated

everytransaction.AsMasterCardSecureCodeevolved,bothretailersandissuers

beganpracticingactiveriskmanagementandnowonlythosetransactions

deemedhigh-riskareauthenticated.Thisrisk-managementisdrivingthe

adoptionofdynamicsolutionsandresultinginareductioninuseoftheinitial

staticpasswordsolution.

MasterCardnowformallysupportsthisriskbasedapproachformerchants.

ThemostcommonofthesecardholderauthenticationsolutionsforMasterCard

andMaestro®issuershasbeentheuseofstaticordynamicpasswords.

DynamicpasswordusagecanbebasedontheChipAuthenticationProtocol

(CAP)thatprovidesforthecreationofaone-timeusecardholderauthentication

password.Thisscenarioissimilartowhatthecardholderexperiencesinthe

face-to-faceenvironmentusingEMVchipcardandpersonalidentification

number(PIN)andusingtheexistinginvestmentsinEMVfornewauthentication

purposes.ThisprogramprovidesaseamlessintegrationofbothEMVand3-D

Securetechnologiesthatresultinstrongerauthenticationthantraditionalstatic

passwordsolutions.Currently,manynewimplementationstakearisk-based

approachtoauthenticationandtheuseofdynamiccodes,increasingboththe

strengthofsecuritywhilealsoimprovingthecustomerexperience.

MasterCardSecureCodeistheconsumer-andmerchant-facingnameforall

existingandnewMasterCardcardholderauthenticationsolutions.While

thesesolutionsmayeachappearquitedifferentonthesurface,thesevarious

approachesconvergearoundtheUniversalCardAuthenticationField™(UCAF)

mechanismandshareanumberofcommonfeatures.

TwocommonfeaturesinallMasterCardcardholderauthenticationsolutions

include:

•MasterCardcardorMaestrocardcardholdersareauthenticatedusinga

secure,unique,privatecode.

•Theauthenticationdataistransportedfromparty-to-partyviatheMasterCard

UCAFmechanism.

1-217June2014•MasterCardSecureCode—MerchantImplementationGuide

SecureCodeMerchantImplementationOverview

MasterCardSecureCodeProgramPlatform

TheMasterCard®SecureCode™programplatformiscomprisedofanumberof

layeredcomponents.

Asdescribedinthefollowingsections,eachofthecomponentsprovidesfor

specificauthorizationandauthenticationfunctionalityduringtheprocessingof

aMasterCardSecureCodetransaction.Whencombined,theplatformprovidesa

mechanismforonlinemerchantstoreceiveasimilarglobalpaymentguarantee

toonethatbrick-and-mortarretailersenjoywithPOStransactions.

WhatisUCAFandItsStructure?

UniversalCardholderAuthenticationField™(UCAF)isastandard,globally

interoperablemethodofcollectingcardholderauthenticationdataatthepoint

ofinteractionacrossallchannels,includingtheInternetandmobiledevices.

ThisisalsoknownastheAccountholderAuthenticationValue(AAV).

WithintheMasterCardauthorizationnetworks(thatistheSingleMessage

andDualMessageSystem,andRSC)UCAFisauniversal,multi-purposedata

transportinfrastructurethatisusedtocommunicateauthenticationinformation

amongcardholder,issuer,merchant,andacquirercommunities.Itisavariable

length,32-positionfieldwithaflexibledatastructurethatcanbetailoredto

supporttheneedsofavarietyofissuersecurityandauthenticationapproaches.

ThegenericstructureofUCAFisillustratedasfollows:

Thecontrolbytecontainsavaluethatisspecifictoeachsecurityapplication.

MasterCardisresponsibleforassigningandmanagingUCAFcontrolbytevalues

andthestructureofUCAFapplication-specificdata.Othersolutionsthatuse

UCAFforauthenticationcollectionandtransportwillbeassignedtheirown

controlbytevalueandthestructureoftheapplication-specificdatawillbe

tailoredtosupportthespecificsofthesecurityprotocol.

MasterCardSecureCode—MerchantImplementationGuide•17June20141-3

SecureCodeMerchantImplementationOverview

MasterCardSecureCodeProgramPlatform

InmostUCAFimplementations,theapplication-specificdataisdefinedasbinary

datawithamaximumlengthof24binarybytesincludingthecontrolbyte.

However,therearesomerestrictionsinthevariousMasterCardauthorization

networksregardingthepassingofbinarydataintheauthorizationmessages.

Asaresult,allUCAFdatageneratedbySecurePaymentApplication™(SPA)

algorithm-basedMasterCard®SecureCode™implementationsmustbeBase64

encodedatsomepointpriortobeingincludedintheauthorizationmessage.

Thepurposeofthisencodingistoproduceacharacterrepresentationthatis

approximately33percentlargerthanthebinaryequivalent.Forthisreason,

theUCAFfieldisdefinedwithamaximumlengthof32positions.Formore

informationaboutBase64coding,refertotheMasterCardSecureCodeSPA

AlgorithmSpecificationsappendix.

ThecurrentMasterCardSecureCodecontrolbytedefinitionsincludethe

following.

Usage

Base64

EncodedValue

Hexadecimal

Value

3-DSecureSPAAccountholderAuthentication

Value(AAV)forfirstandsubsequent

transactions

jx‘8C’

3-DSecureSPAAA Vforattemptshx‘86’

WhatisanAAV?

TheAccountholderAuthenticationValue(AAV)isaMasterCard®SecureCode™

specifictokenthatusestheUniversalCardholderAuthenticationField™(UCAF)

fieldfortransportwithinMasterCardauthorizationmessages.

Itisgeneratedbytheissuerandpresentedtothemerchantforplacementin

theauthorizationrequest.ThisAA Vcanbeproofofafullyauthenticatedoran

attemptedauthenticationtransaction.

Inthecaseofachargebackorotherpotentialdisputeprocessing,theAAVis

usedtoidentifytheprocessingparametersassociatedwiththetransaction.

Amongotherthings,thefieldvalueswillidentifythe:

•IssuerACSthatcreatedtheAAV.(ThiscouldbetheIssuerACSor,inthe

caseofanattempt,theMasterCardAttemptprocessingserver.)

•Sequencenumberthatcanpositivelyidentifythetransactionforthatlocation

•SecretkeyusedtocreatetheMessageAuthenticationCode(MAC),which

isacryptographicmethodthatensuresAAVdataintegrity,andbindsthe

entireAAVstructuretoaspecificPAN.

UCAFisthemechanismthatisusedtotransmittheAA Vfromthemerchantto

issuerforauthenticationpurposesduringtheauthorizationprocess.

1-417June2014•MasterCardSecureCode—MerchantImplementationGuide

SecureCodeMerchantImplementationOverview

MasterCardSecureCodeProgramPlatform

WhatisaMerchantPlug-In

Amerchantplug-inisasoftwareapplicationthatisdevelopedandtestedtobe

compliantwiththe3-DSecureprotocolandinteroperablewiththeMasterCard®

SecureCode™infrastructure.

Theplug-inapplicationistypicallyprovidedbyatechnologyvendorand

integratedwiththemerchant’scommerceserver.Itservesasthecontrolling

applicationfortheprocessingof3-DSecuremessages.

AspartoftheMasterCardSecureCodeinfrastructurerequirements,allmerchant

endpointsmustimplementapplicationsoftwarecapableofprocessing3-D

Securemessages.Anendpointisdescribedasanymerchantormerchant

processorplatform,whichdirectlyconnectstotheMasterCardSecureCode

infrastructure.

NOTE

IfaretailerhasqualiedandacceptedamerchantfortheMasterCardAdvance

RegistrationProgram(MARP),thenMasterCardwillassignastaticAccountholder

AuthenticationValue(AAV)forusewhenthetransactionisundertakenas

MARPinsteadofstandardMasterCardSecureCode.Thisvalueispassedin

plaintextintheUniversalCardholderAuthenticationField™(UCAF)eld.For

additionalinformation,refertotheMasterCardAdvanceRegistrationProgram

Requirementsappendix.

MasterCardSecureCode—MerchantImplementationGuide•17June20141-5

Chapter23-DSecureSolution

ThissectionprovidesanoverviewoftheMasterCardimplementationof3-DSecurefor

MasterCard®cardsandMaestro®cards,includingcardholderenrollmentandpayer

authentication.

3-DSecureSolutionOverview.......................................................................................................2-1

Components...................................................................................................................................2-1

IssuerDomain..........................................................................................................................2-2

AcquirerDomain.....................................................................................................................2-3

InteroperabilityDomain...........................................................................................................2-3

3-DSecureSolutionMessageTypes..............................................................................................2-5

CardRangeRequest/Response................................................................................................2-5

VerificationRequest/Response.................................................................................................2-5

PayerAuthenticationRequest/Response..................................................................................2-6

PayerAuthenticationTransactionRequest/Response..............................................................2-6

CardholderEnrollment...................................................................................................................2-6

CardholderEnrollmentProcess................................................................................................2-7

CardholderAuthentication.............................................................................................................2-7

SampleCardholderAuthenticationProcess.............................................................................2-7

SampleCardholderAuthenticationFlow...............................................................................2-10

MasterCardSecureCode—MerchantImplementationGuide•17June20142-i

3-DSecureSolution

3-DSecureSolutionOverview

Cardholderauthenticationistheprocessofverifyingcardholderaccount

ownershipduringapurchasetransactioninanonlineelectroniccommerce

environment.

AllMasterCard®SecureCode™solutionsdefineandprovideabaselevelof

securityaroundperformingthisauthenticationprocess.Forthissolution

specifically,MasterCardisdeployingitsownimplementationof3-DSecure

undertheMasterCardSecureCodeprogrambrandingforMasterCard®and

Maestro®.Thisimplementationof3-DSecureincludessupportfortheSecure

PaymentApplication™(SPA)algorithmandUniversalCardholderAuthentication

Field™(UCAF)withoutanychangestothe3-DSecurespecification,messages,

orprotocol.

Thecomponentsdescribedhereinareorganizedaccordingtorequirementsthat

fallwithintheissuer,acquirer,andinteroperabilitydomainsassociatedwith

thepaymentprocess.

•IssuerDomain—Systemsandfunctionsofthecardissuingfinancial

institutionsanditscustomers.

–CardholderBrowser

–RelatedCardholderSoftware

–EnrollmentServer

–AccessControlServer

–AccountholderAuthenticationValue(AA V)ValidationServer/Process

•AcquirerDomain—Systemsandfunctionsoftheacquireranditscustomers.

–MerchantPlug-In

–SignatureValidationServer

•InteroperabilityDomain—Systems,functions,andmessagesthatallowthe

IssuerDomainandAcquirerDomaintointeroperate.Thesecomponents

willbegloballyoperatedandmanagedbyMasterCard.

–DirectoryServer

–CertificateAuthority

–MasterCardAuthenticationHistoryServer

–AttemptsProcessingServer(Stand-InAuthentication)

Components

FollowingisinformationaboutcomponentsrelatedtotheIssuerDomain,

AcquirerDomain,andInteroperabilityDomain.

MasterCardSecureCode—MerchantImplementationGuide•17June20142-1

3-DSecureSolution

Components

IssuerDomain

TheIssuerDomainiscomprisedofthefollowingcomponents.

•Cardholderbrowserandrelatedsoftware

•Enrollmentserver

•Accesscontrolserver

•AccountholderAuthenticationValue(AA V)validationserver/process

CardholderBrowserandRelatedCardholderSoftware

TheCardholderbrowseractsasaconduittotransportmessagesbetweenthe

MerchantServerPlug-In(intheAcquirerDomain)andtheAccessControl

Server(intheIssuerDomain).Optionalcardholdersoftwaretosupport

implementationssuchaschipcardsmayalsobeincluded.

Boththebrowserandrelatedsoftwareareconsideredtobeoff-the-shelf

componentsthatdonotrequireanyspecificmodificationtosupport3-DSecure.

EnrollmentServer

Thepurposeoftheenrollmentserveristofacilitatetheprocessofcardholder

enrollmentforanissuer’simplementationof3-DSecureundertheMasterCard®

SecureCode™program.Theserverwillbeusedtoperforminitialcardholder

authentication,aswellasadministrativeactivitiessuchasSecureCoderesetsand

viewing3-DSecurepaymenthistory.Insomecases,theenrollmentserverand

theaccesscontrolservermaybepackagedtogether.

AccessControlServer

Theaccesscontrolserverservestwobasic,yetvital,functionsduringthecourse

ofaMasterCardSecureCodeonlinepurchase.First,itwillverifywhetheragiven

accountnumberisenrolledintheMasterCardSecureCodeprogram.Secondly,

itwillfacilitatetheactualcardholderauthenticationprocess.

AAVValidationServer/Process

Thisserverorprocesswillbeusedtoperformvalidationofthecardholder

authenticationdatareceivedbytheissuer’sauthorizationsysteminthe

authorizationmessages.Issuersmayperformtheirownvalidationorsignupfor

theMasterCard-hostedon-behalfservice.ToregisterfortheMasterCard-hosted

on-behalfservice,sendanemailtoyourregionalCustomerImplementation

Serviceteam.

2-217June2014•MasterCardSecureCode—MerchantImplementationGuide

3-DSecureSolution

Components

MasterCardrecommendsthatissuersvalidatetheAAVcontainedinthe

authorizationmessagepriortotheauthorizationdecision.Thisisconsidered

abestpractice,althoughitisnotrequired.Withtheimplementationofthe

MasterCardAttemptsProcessingService(Stand-InAuthentication),issuersthat

performself-AAVvalidationwillcontinuetobeabletovalidateAA Vvalues

generatedbytheirAccessControlServer(ACS)service.However,anissuerwill

nothavetheabilitytovalidateanattemptAAVgeneratedbytheMasterCard

AttemptsProcessingService.IssuersthatparticipateintheAA Vvalidation

on-behalfservicewillhaveallAA Vvaluesvalidated.

TheserveroftheMasterCardAttemptsProcessingServicewillgeneratean

attemptAAVwhen:

•TheIssuer’saccountrangesdonotparticipateinMasterCardSecureCode.

•TheIssuer’sACSrespondsnegativetothemerchantenrollmentverification

message(VERes=N)forunenrolledcardholders.

•TheIssuer’sACStimesoutorisunavailable.

Underthesecircumstances,anissuerwillnotbeabletovalidateaMasterCard

generatedattemptsAA V.Forsecurityreasons,thekeyswillnotbeshared.

AcquirerDomain

TheAcquirerDomainiscomprisedofthefollowingcomponents.

•Merchantplug-in(MPI)

•Signaturevalidationserver

MerchantPlug-In

Themerchantserverplug-increatesandprocessespayerauthentication

messagesandthenreturnscontroltothemerchantsoftwareforfurther

authorizationprocessing.Theplug-inisinvokedafterthecardholderfinalizes

thepurchaserequest,whichincludesselectingtheaccountnumbertobeused,

andsubmittingtheorderbutpriortoobtainingauthorizationforthepurchase.

SignatureValidationServer

Thesignaturevalidationserverisusedtovalidatethedigitalsignatureon

purchaserequeststhathavebeensuccessfullyauthenticatedbytheissuer.This

servermaybeintegratedwiththemerchantplug-inormaybeaseparately

installedcomponent.

InteroperabilityDomain

TheInteroperabilityDomainiscomprisedofthefollowingcomponents.

MasterCardSecureCode—MerchantImplementationGuide•17June20142-3

3-DSecureSolution

Components

•Directoryserver

•Certificateauthority

•MasterCardAuthenticationHistoryServer

•Attemptsserver

DirectoryServer

TheMasterCard®SecureCode™globaldirectoryserverprovidescentralized

decision-makingcapabilitiestomerchantsenrolledintheMasterCard

SecureCodeprogram.Basedontheaccountnumbercontainedinthemerchant

enrollmentverificationrequestmessage,thedirectorywillfirstdetermine

whethertheaccountnumberispartofaparticipatingMasterCardorMaestro®

issuer’scardrange.Itwillthendirecteligiblerequeststotheappropriate

issuer’saccesscontrolserverforfurtherprocessing.

AllimplementationsofthisissuerplatformmustusetheMasterCardSecureCode

globaldirectoryserverforprocessingMasterCardandMaestro®transactions.

CerticateAuthority

TheMasterCardCertificateAuthorityisusedtogenerateanddistributeall

privatehierarchyend-entityandsubordinatecertificates,asrequired,tothe

variouscomponentsacrossallthreedomains.

Thesecertificatesinclude:

•MasterCardRootcertificate(usedforbothMasterCardandMaestro)

•SSLServerandClientcertificatesissuedundertheMasterCardhierarchy

forcommunicationtotheDirectoryServerandMasterCardAuthentication

HistoryServer

•IssuerDigitalSigningcertificatesissuedundertheMasterCardhierarchyfor

communicationtotheDirectoryServerandHistoryServer

Inaddition,SSLcertificatesbasedonapublicroothierarchyarerequired.These

certificatesarenotissuedbytheMasterCardCertificateAuthorityandmustbe

obtainedfromanothercommerciallyavailablecertificate-issuingprovider.

Formoreinformation,refertotheMasterCardSecureCode—Production

Proceduresmanual.

MasterCardAuthenticationHistoryServer

TheHistoryServerisacentralrepositoryofallauthenticationactivityoccurring

withintheissuerACSforalltransactionsthatoccurred,includingthePAReq

andPAResdetails.

AttemptsServer

TheMasterCardSecureCodeinfrastructuresupportsthiscomponentserver.

2-417June2014•MasterCardSecureCode—MerchantImplementationGuide

3-DSecureSolution

3-DSecureSolutionMessageT ypes

TheMasterCardAttemptprocessingserverprovidesthemerchantwithan

AttemptAccountholderAuthenticationValue(AAV)when:

•TheIssueraccountrangeisnotparticipatingontheMasterCardSecureCode

DirectoryServer.

•TheIssuersendsaverifyenrollmentresponsewiththevalueofanN

(Cardholdernotenrolled).

•TheIssuerACSisUnavailableortimesout.

IssuersmaychoosetohavetheirACSprovidertosendaVEres=Yfor

non-enrolledcardholders,andthenprovidingthePAres=Atoavoidinvoking

theMasterCardAttemptsProcessingService.

TheAA VgeneratedbytheattemptsServerservicewillbegeneratedwith

MasterCardkeyswhichwillnotbeshared.AnissuercanidentifyanAAV

generatedbythenewMasterCardAttemptsProcessingServicebytheACS

identifierinthebase64decodedversionoftheAAV.

3-DSecureSolutionMessageTypes

Thecardrangerequest/response,theverificationrequest/response,thepayer

authenticationrequest/response,andthepayerauthenticationtransaction

request/responseareallmessagetypesassociatedwiththe3-DSecureSolution

process.

CardRangeRequest/Response

CardRangeRequest/Response,alsoknownascardrangecaching,isno

longeraviableimplementation.TheMasterCardAttemptsProcessingService

generatesaStand-InAuthenticationforcardholdersnotenrolled,cardranges

notparticipating,andAccessControlServer(ACS)servicesnotresponding.

ThisAttemptsAccountholderAuthenticationValue(AA V)isonlyprovided

uponMerchantPlug-In(MPI)communicationtotheDirectoryServerforeach

transaction.Thisensuresproperprocessingbyallparties.

VericationRequest/Response

MessagePair:VEReq/VERes—Thefirststepinthepayerauthenticationprocess

istovalidatethatthecardholderaccountnumberispartofanissuer’scard

range,whichisparticipatingin3-DSecure.

TheVerificationRequest/ResponsemessagesaresentfromtheMerchantServer

Plug-IntotheDirectorytocheckcardrangeeligibility.Ifthespecifiedaccount

numberiscontainedwithinaMasterCard®SecureCode™eligiblecardrange,

thismessageisthensentfromtheDirectorytotheAccessControlServer(ACS)

tocheckifthespecificaccountnumberisenrolledandactivetoparticipatein

3-DSecure.

MasterCardSecureCode—MerchantImplementationGuide•17June20142-5

3-DSecureSolution

CardholderEnrollment

AllmerchantswillneedtocallthedirectoryserverforeveryMasterCard

SecureCodetransactiontoreceiveanAttemptsAccountholderAuthentication

Value(AAV)oranAAVfromtheissuer’sACSprovider.Uponimplementationof

theAttemptsService,MPIserviceswillonlyseeVEResmessagevaluesofY.

TheVEReswillroutetheMerchantPlug-In(MPI)serviceviathecardholder’s

browsertoeitherthecardholder’sACSServiceortheMasterCardAttempts

ProcessingServiceforStand-Inauthentication.

PayerAuthenticationRequest/Response

MessagePair:PAReq/PARes—Afterdeterminingthatacardholderisenrolled

toparticipatein3-DSecure,theactualprocessofpayerauthenticationis

performedforeachonlinepurchase.

ThePayerAuthenticationRequest/Responsemessagesaresentfromthe

MerchantServerPlug-IntotheAccessControlServertoinitiatetheactual

authentication.Atthispointintheprocess,cardholderswillbepresentedwith

anauthenticationwindowandaskedtoentertheirSecureCodeorone-time

password(OTP).

TheAccessControlServer(ACS)willperformauthenticationand,ifsuccessful,

generateanAccountholderAuthenticationValue(AAV).Itisreturnedtothe

merchantwithinthePAResmessage.Forsuccessfullyauthenticatedtransactions

andAttempts,thisAAVmustbesentbythemerchanttotheacquirerand

forwardedtotheissueraspartoftheauthorizationrequest.ACSproviders

shouldprovideAA Vvaluesforallattempts(PARes=A)whenthecardholderis

notenrolledordeclinesactivationinadditiontothefullyauthenticated(PARes

=Y)transactionstatus.

PayerAuthenticationTransactionRequest/Response

MessagePair:PATransReq/PATransRes—Followingauthentication,itmay

bedesirabletocentralizestorageofauthenticationrequestsforlaterdispute

processing.

ThePayerAuthenticationTransactionRequest/Responsemessagesprovidea

recordofthisauthenticationactivitysentfromtheAccessControlServer(ACS)

totheMasterCardAuthenticationHistoryServer.AllACSserviceprovidersmust

supportthePATransReq/PATransResmessagesfortheHistoryServer.

TheMasterCard®SecureCode™globalinfrastructuresupportstheHistory

Server.AllACSprovidersmustsupportthesemessages.

CardholderEnrollment

ThissectionoutlinesthecardholderenrollmentprocessforMasterCard®

SecureCode™.

2-617June2014•MasterCardSecureCode—MerchantImplementationGuide

3-DSecureSolution

CardholderAuthentication

CardholderEnrollmentProcess

EnrollmentistheprocesswherebyauthorizedMasterCardandMaestro®

brandedcardholderswillactivatetheircardsforaspecificissuer’sMasterCard®

SecureCode™program.

Partoftheplanningprocessforbuildinga3-DSecureinfrastructurewillinvolve

determiningexactlyhowthisprocesswillwork.

Themajorcomponentassociatedwithenrollmentistheenrollmentserver.Itis

responsiblefordrivingtheprocessunderwhichthecardholder:

•Validatesthattheiraccountnumberisdesignatedaseligibletoparticipatein

MasterCardSecureCodebythecardissuingfinancialinstitution.

•Isauthenticatedbythecardissuingfinancialinstitutionthroughthe

validationofsecretquestions,independentlydeterminedbyeachissuer

participatingintheprogram.

•SetsupanddefinestheirMasterCardSecureCode.

•Performsfunctionssuchasprofileadministration(includingSecureCodeand

emailchanges)andreviewofrecentpurchases.

Typically,thefollowingstepsarenecessarytoauthenticatethecardholder:

1.Thecardholdervisitsanissuerenrollmentsite.Thismaybeaccessible,for

example,fromtheissuer’swebsiteorhomebankingsystem.

2.Thecardholderisaskedtoprovideissueridentifiedenrollmentdata.

Duringthisphaseoftheprocess,thecardholderisaskedaseriesofsecret

questionstoproveidentitytotheissueriftheissuerusesstaticpassword

forauthentication.Otherwise,thecardholdersarepre-enrolledwitha

One-timepassword(OTP)solution.

CardholderAuthentication

Followingisinformationaboutthecardholderauthenticationprocess.

SampleCardholderAuthenticationProcess

Thesampleflowthatfollowsassumesthatthecardholderhasalreadyenrolled

intheissuer’sMasterCard®SecureCode™programandobtainedaSecureCode

tousewhileshoppingonlineatparticipatingmerchants.

Thefigurebelowalsoassumesthatallcommunicationchannelsbetweenthe

variouscomponentsareproperlysecuredusingtheSecureSocketLayer(SSL)

protocol.

MasterCardSecureCode—MerchantImplementationGuide•17June20142-7

3-DSecureSolution

CardholderAuthentication

LinkDescription

SSL-1Thecardholdershopsatthemerchantand,whenreadytocheckout,enterstheappropriate

paymentinformation—includingtheaccountnumber.

SSL-2TheMerchantPlug-InqueriestheDirectorytoverifytheenrollmentstatusforaspecific

issuerusingtheverificationrequestmessages.

SSL-3Ifthedirectoryindicatesthatanissuerisparticipating,thenthedirectorymustforwarda

requesttotheissuer’sAccessControlServertochecktheenrollmentstatusofaspecific

cardholder.TheconfigurationinformationintheDirectorywillindicateexactlywhich

AccessControlServerwillperformthecheck.Theresultingresponsewillflowbackover

thesamelinkstotheMerchantPlug-In.

SSL-4IftheAccessControlServerindicatesthataspecificcardholderisparticipating,theMerchant

Plug-IncreatesthePayerAuthenticationRequestmessageandsendsittothecardholder’s

browser.

2-817June2014•MasterCardSecureCode—MerchantImplementationGuide

3-DSecureSolution

CardholderAuthentication

LinkDescription

SSL-5ThecardholderbrowserredirectsthemessagetotheappropriateAccessControlServerto

performcardholderauthentication.WhentheAccessControlServerreceivesthePayer

AuthenticationRequestmessage,itcausestheuserauthenticationdialogtobegin.Thisin

turncausesaseparateauthenticationwindowtoappeartothecardholderthatwillfacilitate

thecardholderauthenticationprocess.

SSL-6TheAccessControlServerauthenticatesthecardholderSecureCode,constructstheSPAAA V

forMasterCard’simplementationof3-DSecure,andbuildsanddigitallysignsthePayer

AuthenticationResponsemessage.ItisreturnedtotheMerchantPlug-In,atwhichpointthe

cardholderauthenticationwindowwilldisappear.

SSL-7TheAccessControlServersendsPATransRectotheMasterCardAuthenticationHistoryServer.

Aftercardholderauthenticationiscomplete,themerchantisrequiredto

passthecorrespondingSecurePaymentApplication™(SPA)Accountholder

AuthenticationValue(AAV)totheacquirerviatheUniversalCardholder

AuthenticationField™(UCAF)withintheauthorizationmessage.Thisvalueis

thenpassedfromtheacquirertotheissueraspartoftheauthorizationmessage.

Whenreceivedbytheissuer,theAA Vcanbevalidatedaspartofauthorization

requestprocessing,aswellasarchivedforuseinpotentialcardholderdisputes.

IssuerswillonlybeabletovalidateanAttemptorfullyauthenticatedAA V

generatedbytheirownACS.IftheMasterCardAttemptsProcessingService

generatesanAA V,itcannotbeissuervalidated.TheMasterCardAttempts

ProcessingServiceusesauniquekeythatcannotbeshared.Forissuerswanting

toensurethatallAA Vsarevalidated,MasterCardofferstheMasterCard-hosted

on-behalfservice.AA VswillalsobegeneratedbytheMasterCardAttempts

ProcessingServiceforStand-InAuthenticationwhencardholdersarenot

enrolled,cardrangesarenotparticipatinginMasterCardSecureCode,orAccess

ControlServer(ACS)servicesarenotresponding.ThisAttemtptsAA Vcanonly

validatethroughtheMasterCardAAVValidationServiceratherthanthrough

self-validation.

MasterCardSecureCode—MerchantImplementationGuide•17June20142-9

3-DSecureSolution

CardholderAuthentication

SampleCardholderAuthenticationFlow

Thefollowingsamplecardholderauthenticationflowisidenticalforboth

MasterCardandMaestro™cardholders.

EnterPaymentInformation

Thecardholderwillshopatamerchantlocationjustastheywouldtoday.

Afterselectingtheitemstobeplacedintotheshoppingcart,thepaymentcard

informationtobeusedforthetransactionisentered.

ConrmandSubmitOrder

Onceallofthepaymentandshippinginformationhasbeenentered,the

cardholderistypicallygivenanopportunitytoreviewthepurchaseonelast

timebeforesubmittingtheorder.

EnterSecureCode

Uponsubmittingthefinalorder,thecardholderwillbepresentedwithan

authenticationwindowfromtheirMasterCardcardorMaestrocard-issuing

bank.Atthispoint,thecardholderwillenterhisorherSecureCodevalueto

performauthenticationprocessing.

PurchaseCompleted

AftervalidationofthecardholderSecureCodebytheissuingbank,the

authenticationwindowwilldisappearandtheauthorizationofthepayment

cardwillcompleteasusual.

2-1017June2014•MasterCardSecureCode—MerchantImplementationGuide

Chapter3Merchants

Thissectionprovidesageneraloverviewofthevariousactivitiesandrequirements

associatedwithbuildingandmaintainingthemerchantcomponentsrequiredtosupport

MasterCard®SecureCode™.

Overview.......................................................................................................................................3-1

MerchantInfrastructure..................................................................................................................3-1

EstablishmentofMasterCardSecureCodeOperatingEnvironment..........................................3-2

AuthorizationSystemMessageEnhancements...............................................................................3-2

PassingtheAA VintheAuthorizationMessage........................................................................3-2

E-CommerceCommerceIndicator...........................................................................................3-3

RecurringPayments.................................................................................................................3-5

MaestroConsiderations..................................................................................................................3-5

Customization................................................................................................................................3-6

MasterCardSecureCodeProgramIdentifierUsageGuidelines.................................................3-6

IntegratedSupportforMerchantPlug-InProcessing...............................................................3-6

ConsumerMessageonPaymentPage.....................................................................................3-8

CreationofCardholderAuthenticationWindow......................................................................3-8

TERMURLField........................................................................................................................3-9

ReplayDetection.....................................................................................................................3-9

MerchantServerPlug-InConfiguration..................................................................................3-10

Operational..................................................................................................................................3-12

LoadingofMasterCardRootCertificates................................................................................3-12

LoadingofMasterCardSSLClientCertificate.........................................................................3-12

MPILogMonitoring...............................................................................................................3-12

MPIAuthenticationRequest/ResponseArchival....................................................................3-13

AAVProcessing............................................................................................................................3-13

GlobalInfrastructureTestingRequirements.................................................................................3-13

MasterCardSiteDataProtectionProgram....................................................................................3-14

MasterCardSecureCodeMerchantProcessandLiabilityShiftMatrix...........................................3-14

MasterCardSecureCode—MerchantImplementationGuide•17June20143-i

Merchants

Overview

Themerchantactivitiesandrequirementsforbuildingandmaintainingthe

merchantcomponentsforMasterCard®SecureCode™aredividedintofive

primarycategories.

CategoryDescription

InfrastructureRequirementsrelatedtoinstallationof

newhardwareandsoftwarecomponents.

CustomizationRequirementsrelatedtocustomizingor

configuringvendorproducts.

OperationalRequirementsrelatedtooperatingthe

componentsinaproductionenvironment,

includinganyprocessorientedchanges

thatmayberequired.

AccountholderAuthenticationValue

(AAV)Processing

Requirementsrelatedtohandlingand

processingoftheAAV.

GlobalInfrastructureTesting

Requirements

Requirementsrelatedtotestingof

MasterCard®SecureCode™platform

components.

NOTE

Inthissection,therearereferencestoamerchantendpoint.Thisistheentity

thatisactuallyoperatingtheMerchantPlug-Insoftware.Thesemayinclude,

forexample,individualmerchants,hostingproviders,andpaymentservice

providers.NotallmerchantsparticipatingintheMasterCardSecureCode

programareconsideredendpoints.

GeneralResponsibilities

MasterCardrequiresallmerchantstoensurethatMasterCardSecureCode

isnottheonlyfraudmanagementtoolusedtomanagefraud.Additional

optionsavailablewithinstandardcardprocessingsuchasCVC2,andAddress

VerificationService(A VS)(availableinsometerritories)shouldalsobeused.

Manysuppliersnowofferfraudmonitoringsystemsthattakeothernon-card

informationavailableforcaptureduringthee-commerceshoppingexperience.

Checkwithyouracquirerorshoppingcart/MPIvendorforoptions.Ifusinga

ServiceProvidertosupplythecheckoutandMasterCardSecureCodeexperience,

additionaloptionsarelikelyavailable.

MerchantInfrastructure

Followingarethemerchantinfrastructurerequirementsfortheinstallation

ofnewhardwareandsoftwarecomponentsthatsupportMasterCard®

SecureCode™.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-1

Merchants

AuthorizationSystemMessageEnhancements

EstablishmentofMasterCardSecureCodeOperating

Environment

AllmerchantsparticipatingintheMasterCard®SecureCode™programare

requiredtoinstallorhaveaccesstoa3-DSecurev1.0.2orhighercompliant

MerchantServerPlug-In.

Foracurrentlistofvendors,goto:

•www.mastercard.us/merchants/securecode-vendors.html

AuthorizationSystemMessageEnhancements

FollowingareenhancementstotheAuthorizationSystemforsupporting

MasterCard®SecureCode™.

PassingtheAAVintheAuthorizationMessage

MasterCardrequiresthattheSecurePaymentApplication™(SPA)Account

AuthenticationValue(AAV)returnedtothemerchantinthePayerAuthentication

Response(PARes)messagebeincludedinallsuccessfullycardholder

authenticatede-commercetransactionsandAttemptsProcessingtransactions

fromeithertheissuer’sAccessControlServer(ACS)providerorMasterCard

AttemptsProcessingService’s“Stand-In”Authentication.

Merchantsmustensurethattheyfollowthemessageformattingrequirements

oftheiracquirerwhengeneratingUniversalCardholderAuthenticationField™

(UCAF)relatedauthorizationrequests.

Followingarepotentialissuestoconsider.

MasterCardrequiresthattheSPAAA Vcontainedintheauthorizationfromthe

acquirertotheissuerbeBase64encoded.Passingthisdatainbinaryformat

isnotanoption.Merchantplug-insoftwaretypicallyprovidestheSPAAAV

returnedinthePAResmessagealreadyinthisformat.Whilesomeacquirers

allowmerchantstosimplypasstheBase64encodedSPAAAVthroughinthe

authorization,othershavevaryingrequirements.

Dependingonthespecificmerchantsystemandacquirermessageformats,it

maybenecessaryfortheSPAAAVtobeconvertedbetweenASCIIandEBCDIC

encodingpriortoitbeingsenttotheacquirer.Anysuchconversionmustonly

beperformedontheSPAAAVafterithasbeenBase64encoded.Anyattempt

tomodifythebinaryrepresentationoftheSPAAAVwillresultincorruption

ofthedataandtheinabilityoftheissuertoperformcardholderauthentication

verificationprocessing.

3-217June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

AuthorizationSystemMessageEnhancements

TheonlyexceptiontotheBase64encodingrequirementofanAA Viswhen

MasterCardsuppliesthisAA VtothemerchantasastaticcodeforuseinMaestro

AdvancedRegistrationProgram(MARP)transactions.ThisstaticAAVmustbe

passedinplaintext.ForadditionalinformationonMARP ,seeAppendixD,

MasterCardAdvanceRegistrationProgram.

FormoreinformationaboutBase64encoding,refertoAppendixB,MasterCard

SecureCodeSPAAlgorithmSpecifications.

Whileanauthenticationstatusof“A”isavalidPAResstatusresponseand

willcontainaSPAAAV,itisnotconsideredtobeasuccessfulcardholder

authentication.TheAAVresultingfromsuchatransactionisidentifiedbya

lowercase“h”inthefirstposition(Base64encoded).Acquirersmustensure

thattransactions.AllAAVsreceivedaspartofaPAResmustbeprovidedin

theAuthorizationRequest/0100messagebyacquirersinDE48(Additional

Data—PrivateUse),subelement43(3-DSecureforMasterCardSecureCode).

Ifquestionsarise,merchantsshouldconsultwiththeiracquirersformore

detailedinformation.RefertotheMerchantProcessingMatrixforadditional

information.

AAVUsage

TheAA VcontainedwithinasingleauthorizationrequestmustmatchtheAAV

valuereturnedbytheissuerforasingleassociatedauthenticationrequest.

Therefore,anAA Vcanbeusedonlyonceinasingleauthorizationmessageand

mustnotbestoredforreuseafterreceivingauthorization.

E-CommerceCommerceIndicator

Anelectroniccommerceindicator(ECI)flagisrequiredtobepresentinall

PAResmessagessentbytheissuerACStothemerchantwhenthestatusfield

containsavalueofYorA.

Ascurrentlydefined,the3-DSecureprotocolindicatesthatthisECIfieldbe

determinedbyeachbrand.Asaresult,MasterCardhasadoptedvaluesthat

maybedifferentfromotherparticipatingpaymentbrands.TheECIvalueis

notthesameastheSecurityLevelIndicator(SLI).TheSecurityLevelIndicator

iscontainedintheAuthorizationRequest/0100messageinDE48(Additional

Data—PrivateUse),subelement42(ElectronicCommerceIndicators),subfield1

(ElectronicCommerceSecurityLevelIndicatorandUCAFCollectionIndicator)

withposition1(SecurityProtocol)containingavalueof2(Channel)and

position2(CardholderAuthentication)containingavalueof1(Cardholder

certificatenotused).Position3(UCAFCollectionIndicator)variesbasedonthe

PAResstatus.IfPAResisN,thenthevalueshouldbe0fornon-SecureCode

standarde-commercetransactionwithoutliabilitysift.IfPAResisY,thenthe

valueshouldbe2forfullyauthenticated.IfthePAResisAorU,thenthe

valueshouldbe1formerchant-onlyauthentication(attempts),whichcarriesa

liabilityshift.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-3

Merchants

AuthorizationSystemMessageEnhancements

WhenthesevaluesareusedwithintheMasterCardauthorizationandclearing

systems,theyarereferredtoasSLIs.Most,ifnotall,acquirersandpayment

processorshavedefinedtheECIasarequiredfieldintheirauthorizationrequest

messageformats.EachmerchantmustensurethattheMasterCardECIvalue

isproperlytranslatedtoavalidvalueasdefinedintheappropriateacquirer

orpaymentprocessorauthorizationmessageformat.Failuretoperformthe

appropriatetranslationmayaffecttheabilitytoobtainsuccessfulauthorizations.

MasterCardhascurrentlydefinedtwoECIvalues.Thefollowingtableindicates

therelationshipbetweenthesevaluesandthestatusfieldinthePAResmessage.

TheECIvalueisnotthesameastheSecurityLevelIndicator.TheSecurity

levelindicatoriscontainedintheAuthorizationRequest/0100messageatDE

48,subelement42,subfield1(ElectronicCommerceSecurityLevelIndicator

andUCAFCollectionIndicator)withposition1(SecurityProtocol)containinga

valueof2(Channel),andposition2(CardholderAuthentication)containing

avalueof1(Cardholdercertificatenotused).Position3(UCAFCollection

Indicator)variesbasedonthePAResstatus.IfPAResisN,thenthevalueshould

be0fornon-SecureCodestandardeCommercetransactionwithoutliabilitysift.

IfPAResisY,thenthevalueshouldbe2forfullyauthenticated.IfthePAResis

AorU,thenthevalueshouldbe1formerchantonlyauthentication(attempts)

whichcarriesaliabilityshift.

AnyquestionsontranslatingMasterCarddefinedvaluesforauthorizationshould

bedirectedtoyouracquirerorpaymentprocessor.

PAResStatus

FieldDescriptionMasterCardECIValue

YCardholderwassuccessfullyauthenticated(SLI=2)02

AAuthenticationcouldnotbecompletedbutaproofof

authenticationattemptwasprovidedSLI=1.

NCardholderauthenticationfailedSLI=0Absent

UAuthenticationcouldnotbecompletedduetotechnical

orotherproblems(SLI=1)

Absent

NOTE

PAResstatusmustcorrelatewiththeECIandSecurityLevelIndicatorchart

shownintheProcessingMaxtrix.TheECIvalueandSecurityLevelIndicator

passedaspartoftheAuthorizationRequest/0100messagearedifferentvalues

andaredenotedintheProcessingMatrix.

NOTE

MasterCardhasadditionaldenitionsofSLIsthatarenotgeneratedbythe

PAResreceivedbutthatmayneedtobeusedbythemerchant.Refertothe

MerchantProcessingMatrixsectionforadditionalinformationonSLIs.(SLI)

3-417June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

MaestroConsiderations

RecurringPayments

Onlytheinitialauthorizationrequestforarecurringpaymentmaybe

e-commercetransactionsandmaycontainUniversalCardholderAuthentication

Field™(UCAF)data.

MerchantsmustnotprovideUCAFdatainanysubsequentrecurringpayment

authorizationsasthesearenotconsideredelectroniccommercetransactions

byMasterCardandarenoteligibleforparticipationintheMasterCard®

SecureCode™program.

Withthefollowingexception,Maestro®cardsarenoteligibletobeusedfor

recurringpayments.

RecurringpaymentsonMaestrocardsissuedintheEuroperegionarevalid

butsubjecttospecificacceptancerules.Formoreinformation,refertothe

TransactionProcessingRulesdocument.

MaestroConsiderations

Thefollowingrequirementsandactivitiesarespecifictomerchantsupportof

Maestro®cardsaspartoftheMasterCard®SecureCode™program.Contactyour

acquirerforacompletesetofMaestroe-commerceacceptancerequirements.

RequireduseofMasterCardSecureCode

Maestrorulesrequirethatalle-commercemerchantsacceptingMaestrocards

mustuseMasterCardSecureCodeforalltransactions,orapplyandbeaccepted

forentrytoMaestroAdvancedRegistrationProgram(MARP).SeeAppendixF,

MasterCardAdvanceRegistrationProgramforadditionalinformation.

AccountNumberLengthRequirements

Maestromerchantsmustsupportcardholderaccountnumbersthatare13–19

digitsinlength.

CVC2andMaestro

MerchantsshouldbeawarethatnoteveryMaestrocardinissuancehasaCVC2

andthisshouldbefactoredinduringcheckoutdesign.

MaestroAcceptanceRules

ForadditionalinformationaboutacceptingMaestroine-commerceandthe

rulespertainingtoMaestroAcceptance,refertotheTransactionProcessing

Rulesdocument.

AdditionalMaestroPropositionsandConsiderationsinE-commercewhen

usingMasterCardSecureCode

Foradditionalinformation,refertoAppendixD,MaestroConsiderations.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-5

Merchants

Customization

Followingaremerchantrequirementsforcustomizingorconfiguringvendor

productsinsupportofMasterCard®SecureCode™.

MasterCardSecureCodeProgramIdentierUsageGuidelines

Issuersandacquirersmustadheretotheapplicableusageguidelines.

Merchantsarerequiredtoadheretotheapplicableusageguidelines.

TheseguidelinesareindicatedintheMasterCardSecureCodeProgramIdentifier

Guidelinesaccessedusingthefollowingwebaddress:

www.mastercard.com/us/merchant/secu-

rity/what_can_do/pdf/SecureCode_logo_usage.pdf

ProofofadherencetotheseguidelinesmustbeprovidedtoMasterCardasa

conditionofsuccessfulcompletionofMasterCard®SecureCode™merchant

orserviceproviderfunctionaltesting.

MasterCardhighlyrecommendsthatallscreenshotsbeprovidedforreviewas

soonaspossibleincasechangesarerequired.

AcopyoftheMasterCardSecureCodelogoartwork,aswellasanyupdates

totheprogramidentifierusageguidelines,isavailablefordownloadat

www.mastercardbrandcenter.com/us/getourbrand/index.shtml.

IntegratedSupportforMerchantPlug-InProcessing

Thefollowingdiagramdepictsasamplehigh-levelflowofatransactionthrough

amerchant’se-commercesitethathasintegratedsupportforMasterCard®

SecureCode™.

ThefollowingfigureindicatesmerchantbestpracticesregardingMasterCard

SecureCodeprocessing.

3-617June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

Customization

MasterCardSecureCode—MerchantImplementationGuide•17June20143-7

Merchants

Customization

ConsumerMessageonPaymentPage

MasterCardrecommendstheuseofaconsumermessageonthepaymentpage

tofurtherindicatemerchantparticipationintheprogram.

CreationofCardholderAuthenticationWindow

The3-DSecureprotocolisdesignedsothatthecreationofthecardholder

authenticationwindowisperformedbythemerchant.

Theactualcontentofthewindowiscontrolledbytheissuer.Therearetwo

primarymethodsforcreationofthiswindow,howeveronlyoneapproach,

inlinewindows,isnowacceptablefordeployment.andexistingmerchantsare

expectedtoconverttoaninlinewindowimplementation.

NOTE

Previousimplementationapproachesbasedonpop-upauthenticationwindows

arenolongersupportedfornewmerchantimplementations.Astherequirement

toceaseusingpop-upwindowshasbeeninplacesince2005,anymerchantthat

isfoundtosupportapop-upwindowwillbedeemedasoutofcompliancewith

MasterCard®SecureCode™andmayhavetheirfacilityterminatedormaybe

liableforassessments.MasterCardrecommendsthatmerchantschecktheir

checkoutprocessandspeaktotheirserviceprovidersonthispoint.

Pop-UpAuthenticationWindows

MasterCardprohibitsthistypeofimplementation.

InlineWindows

Inlinewindowimplementations,whichhaveproventovirtuallyeliminatethe

issuescausedbypop-upauthenticationwindows,arerequiredforallnew

merchantimplementations.Existingpop-upimplementationsmustconvertto

inlinewindows.Bypresentingafull-pageview,theMasterCardSecureCode

authenticationprocessappearstobeaseamlesspartofthemerchantcheckout

process,particularlywhenthemerchantusesthe“withframes”approach

describedinthefollowingparagraphs.

WithFrames

Aframeimplementationallowsthemerchanttodisplayabrandedheaderand

explanationtextthatcanassistcardholderswhoarenewtotheMasterCard

SecureCodeexperience.Inaframeimplementation,onlypartofthefull

windowisredirectedtotheissuer’saccesscontrolserver.

MasterCardprovidesthefollowingguidelinesandspecificationsformerchants

thatchoosetoimplementtheframesapproach:

3-817June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

Customization

•TheuseofactiveHTMLlinksinthebrandedheaderframeisnotallowed.

MasterCardrecommendsincludingalinkbelowtheheaderframethatdirects

thecardholderbacktothecheckoutpageincaseoftechnicaldifficulties.

•Theexplanationtextshouldbeclearandconcise.Thetextshouldnot

assumethatthecardholderisalreadyenrolledinMasterCardSecureCode

andshouldnotprovideinstructionsthatmightconflictwiththecardholder’s

issuerinstructions.

•Themerchantshouldensurethattheauthenticationwindowframeisfully

visibleandisnotlocatedtoolowinthepagebecauseoflongtextor

largeupperframe.Aminimumspaceof400x400pixelsisrequiredfor

theACSframe.

•Merchantsmustensurethatthe“back”buttonfunctionalityworksproperly

andthatcardholderswillberoutedbacktothecheckoutpage.

WithoutFrames

MasterCardresearchandfeedbacksuggeststhatcardholdersareuncomfortable

withthewithoutframesmethod,thereforeitcancauseahigherabandonment

rate.Theuseofframesaddsthesenseofsecuritythatthecardholderisstill

atthemerchantsiteandisnotbeing“phished.”MasterCardrecommendsthat

thisapproachisnotused.Anymerchantcurrentlysupportingthiscardholder

experienceisencouragedtomovetoa“frame”experience.

TERMURLField

TheTERMURLisafieldthatisprovidedbythemerchanttotheissuerduring

thepayerauthenticationrequestprocess.

ThisfieldprovidestheissuerwiththemerchantURLwherethepayer

authenticationresponsemessageistobesent.TheuseofmixedHTTP

andHTTPSframestypicallyresultsinasecurityboxbeingpresentedtothe

cardholder.Dependingonhowthecardholderrespondstothisdialog,the

currentandallfutureattemptstotransmitthePAReqmessagemayfail.

NOTE

Merchantsusinginlineauthenticationwindowswithframesmustpopulatethe

TERMURLeldwithanHTTPSaddress.

ReplayDetection

Manyissueraccesscontrolserversattempttodetectreplayattacksbynot

allowingatransactionwiththesameaccountIDandXIDtobeprocessed

morethanonce.

MerchantsmustensurethateachPayerAuthenticationRequest(PAReq)contains

auniquecombinationofaccountIDandXID.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-9

Merchants

Customization

MerchantServerPlug-InConguration

Followingisserverplug-ininformationformerchants.

InitializationofMasterCardDirectoryURL

EachmerchantendpointmustconfiguretheMPIsoftwaretocommunicatewith

theMasterCard®SecureCode™Directoryserver.

InitializationofMPIProcessingTimers

Followingisinformationaboutcacheexpirationtimersandtransactiontime-out

timers.

CacheExpirationTimers

MasterCardrecommendsthatmerchantssendaVEReqtothedirectoryforeach

transactionratherthanusingcachingtoverifycardrangeparticipationinthe

program.WiththeimplementationoftheMasterCardAttemptsProcessing

Service’s“Stand-In”Authentication,allmerchantsmustsendallVEReqto

theDirectoryServertoensurereceiptofAA Vvaluetoincludewithinthe

AuthorizationRequest/0100message.

TransactionTime-outTimers

Transactiontime-outperiodsdeterminehowlongtowaitforaresponsetoa

VerificationRequestmessageandaPayerAuthenticationRequestmessage.

InthecaseofPAReq/PAResprocessingspecifically,thewaittimesmayvary

becauseoftherequirementforcardholderinteraction.Inpractice,however,

manyfinancialinstitutionsareusingexistingconsumercredentials(forexample,

homebankingpasswords)fortheMasterCardSecureCodeprogram.Assuch,

issuesrelatedtotimeconsumingfunctionssuchasforgottenpasswordsare

minimized.

MasterCardrecommendsthefollowingbestpracticesregardingtime-outvalues:

FunctionTime-OutValues

Actioniftimerexpirespriorto

receiptofresponse

VerifyEnrollmentRequest20SecondsContinueasifthecardholder

isnotenrolledintheprogram

(forexampleVERestransaction

status=“N”).Thismeansthe

AuthorizationRequest/0100

messageshouldbesentwitha

SecurityLevelIndicatorof211

(MerchantOnlyauthentication

transaction[liabilityshiftapplies]).

Withtheimplementationofthe

MasterCardAttemptsProcessing

Service,thisshouldnotoccur

3-1017June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

Customization

FunctionTime-OutValues

Actioniftimerexpirespriorto

receiptofresponse

unlesstheDirectoryServeris

unavailable.

PayerAuthenticationRequestMasterCardrequiresthatthe

merchantallowaminimumof

fiveminutesforreturnofthe

PARes,andrecommendsthatthe

merchantallowupto10minutes

forreturnofthePARes.

Continueasifcardholder

authenticationfailed(forexample

PARestransactionstatus=“N”).

ThismeanstheAuthorization

Request/0100messageshould

besentwithaSecurityLevel

Indicatorof210(non-SecureCode

transaction[noliabilityshift]).

InitializationofMPIProcessingParameters

ThereareanumberofMPIconfigurationparameterswhich,ifnotsetproperly,

maycause3-DSecureprotocolviolations.

Allmerchantsmustensurethattheirimplementationplansaccountforthe

followingfieldrestrictions:

•Themerchantnamewithinanyapplicablemessagemustbelessthanor

equalto25charactersincludingspaces.

•ThemerchantURLfieldinthePAReqmessagemustbefullyqualified

and,ideally,shouldbetheURLofthemerchanthomepage.ManyACS

providerspresentthisURLtocardholders,includinganactiveHTMLlink

thatdirectscardholderstothisaddress.

•Themerchantcountrycodemustbeavalid,3digit,ISO3166countrycode.

•Thepurchasecurrencycodemustbeavalid,3digit,ISO4217currency

code.

TERMURL

MerchantsmustensurethattheTERMURLusedfortestingismodifiedto

properlyreflecttheproductionenvironment.Inaddition,theTERMURLfield

mustbefully-qualified.

ZeroorEmptyParameters

MerchantsmustmakesurethatallparameterssenttotheACSarevalidand,

unlessotherwiseindicatedbythe3-DSecureprotocol,donotcontainzeroor

emptydataelements.Forexample:

1.Thetransactionamountshouldcontainanon-zeroamount.APayer

AuthenticationRequest(PAReq)transactionamountofUSD0isrequired

tonotauthenticatetransparentlywithRiskBasedAuthentication.This

isbecausetheMerchantPlugIn(MPI)processbeingusedistoactually

authenticatethecardholder.Thismayoccurwhenenrollingacardwithin

anOnlineWallet.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-11

Merchants

Operational

2.Asdefinedbytheprotocol,theMDfieldmustalwaysbeprovided,even

ifitisnotused.

3.Ifoptionalfieldsarenotused,MasterCardrecommendstheybeexcluded

fromthemessageinsteadofusingemptydataelements.

Operational

FollowingareMasterCard®SecureCode™operationalguidelinesformerchants.

LoadingofMasterCardRootCerticates

MerchantendpointsarerequiredtoloadallactiveandpendingMasterCard

Roothierarchycertificates.

Thisrootwillberequiredbythemerchantplug-intoperformdigitalsignature

validation.ItmayalsoberequiredinordertoestablishSSLsessionsusing

certificatesbasedontheMasterCardprivatehierarchy.

NOTE

Currently,MasterCardhastwoactiverootcerticatesthatmustbeloaded.

LoadingofMasterCardSSLClientCerticate

MerchantendpointsareresponsibleforobtainingallnecessarySSLclientand

servercertificatesforusebytheMPIplatform.

IndividualmerchantswillberequiredtouseasingleMasterCardhierarchy

SSLclientcertificatefortheiracquirer.Ifaprocessorisusingthemerchant

plug-in,MasterCarddoesnotrequireanindividualcertificateforeachmerchant.

However,theprocessorwillberequiredtouseaseparateanddistinctclient

certificateforeachapplicableacquirer.

Formoreinformationaboutcertificaterequirementsandprocedures,seethe

MasterCardSecureCode—ProductionProceduresmanual.

MPILogMonitoring

MerchantendpointsshouldestablishapolicyofmonitoringMPIlogsforvarious

authenticationfailuremessages,includingsignaturevalidationfailures.

Repeatedfailuresshouldbereportedtothemerchant’sacquirer.Merchants

shouldnotethatthiscouldbeanindicationofissuessurroundingthe

MasterCard®SecureCode™implementationwithpossiblelossofLiabilityShift

orcostbenefitsonthesetransactions.

3-1217June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

AAVProcessing

MPIAuthenticationRequest/ResponseArchival

Merchants,ormerchantendpoints,shouldestablishapolicyforarchivalof

authenticationrequestandresponsemessages.

MasterCardrecommendsthatthearchivalperiodforthisdatabethesameasthe

associatedauthorizationtransactiondata,andshouldbeaminimumof180days.

AAVProcessing

Thefollowingprocessingstepsarerequiredbythe3-DSecureprotocoland

typicallyhandledbytheMPI.Anysubsequentprocessingistheresponsibility

ofthemerchant.

IdenticationofSPAAAVFormatinPARes

TheCAVValgorithmfieldinthePAResmessageindicatesthealgorithm

usedtocreatethecryptogramcontainedintheCA VVfield.AllMasterCard

AccountAuthenticationValue(AAV)valueswillbeidentifiedwithavalueof

3(MasterCardSPAAlgorithm).Thisistheonlyvaluethatispermittedfor

MasterCardandMaestro®cardtransactions.

ValidationofPayerAuthenticationResponse(PARes)Signature

AllPAResmessagesreturnedtothemerchantaredigitallysignedbythe

associatedcardholder’sissuerACSusingcertificatesprovidedbyMasterCard

ortheAttemptsProcessingServer.Themerchantisrequiredtovalidatethe

signaturepriortoextractingtheSecurePaymentApplication™(SPA)AA Vfrom

thePAResmessageforinclusionintheauthorizationrequestsenttotheacquirer.

TheAAVvalueinthePAResmustbeconsideredunusableifthesignature

validationprocessfails.

GlobalInfrastructureTestingRequirements

AllmerchantendpointsarerequiredtocompleteMasterCard®SecureCode™

functionaltesting.ThisincludesexecutionoftheMasterCardSecureCodeSystem

TestAgreement,whenapplicable,aswellasremittanceofapplicablefees.

Thepurposeforthistesting,whichonlyencompassescardholderauthentication

testing,istoensurethatmerchantimplementationsmeetminimumfunctional

andbrandrequirementsforparticipatingintheMasterCardSecureCode

program.Anyadditionalauthorizationtestingshouldbecoordinatedthrough

theappropriatemerchantacquirerorprocessor.

ForadditionalinformationontheMasterCardSecureCodetestingprocess,send

arequestviaemailtosecurecode_customer_support@mastercard.com.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-13

Merchants

MasterCardSiteDataProtectionProgram

TheMasterCardSiteDataProtectionProgram(SDP)representsacriticalpiece

intheMasterCardcomprehensiveapproachtopaymentcardsecurity.

AllmerchantsimpactedbytheSDPmandatemustdemonstratecompliance

withthePaymentCardIndustryDataSecurityStandard(PCI-DSS)security

requirementstotheiracquirer.FormoreinformationaboutSDP ,contactyour

acquirerorvisitwww.mastercard.com/sdp.

MasterCardSecureCodeMerchantProcessandLiability

ShiftMatrix

Thefollowingtableillustratesmerchantbehaviorduringvariouspotential

scenariosassociatedwithMasterCard®SecureCode™authenticationrequest

processing.

MasterCardSecureCodeProcessingMatrix

ToaccesstheMasterCardSecureCodeProcessingMatrixinaMicrosoft®Excel®

formatthatcanbecopiedandusedasneeded,clickhere.Thisfilecanbe

savedtoalocaldriveforlateruse.

CISDE48(AdditionalData—PrivateUse)Components

Theseindicators,aslistedinthetableabove,maptoMasterCardAuthorization

specificationrequirementsforacquirersandissuers.DE48,subelement42

(ElectronicCommerceIndicators),subfield1(ElectronicCommerceSecurity

LevelIndicatorandUCAFCollectionIndicator)containstheSecurityLevel

IndicatorandDE48,subelement43(UniversalCardholderAuthenticationField

[UCAF])containstheUCAFData(AA V).Merchantsmustrefertotheappropriate

acquirerorpaymentprocessormessagespecificationsforspecificformatting

requirements.

3-1417June2014•MasterCardSecureCode—MerchantImplementationGuide

Merchants

MasterCardSecureCodeMerchantProcessandLiabilityShiftMatrix

MerchantRisk-BasedApproach

AmerchantisnotrequiredtoundertakeMasterCardSecureCodeonevery

transactionexceptwhenacceptingMaestro®,asthisisarequirementof

theprogram.AnymerchantthatchoosesnottouseaSecureCodeonany

transactionshouldprocessonthebasisofthelastentryinthetableabove

labeled“MerchantNotSecureCode-enabledORSecureCodeNotUsedfor

Transaction”(SLI=210).

FailedAuthentication

Amerchantmayproceedwithatransactionforwhichtheauthenticationfailed,

butitmustbeonaSecureCodenotusedfortransactionbasis(SLI=210).

Thistransactionmustnotbesubmittedasmerchantonlyandisnoteligible

foranyliabilityshift.NoAAVwillbeprovided,andissuersarelikelyto

declinethetransactionifsubmitted.MasterCardreservestherighttoundertake

noncomplianceproceedingsagainstanymerchantoracquirerdeemedtobe

undertakingmerchant-onlytransactionsforfailedauthentications.

LiabilityShift

Afullyauthenticatedliabilityshiftisineffectgloballyforallcommercialand

consumercards.

Merchant-onlyliabilityshiftisineffectgloballyforallconsumercards.

Commercialcardscarrymerchant-onlyliabilityforallinterregionaltransactions

andareonlyexcludedforintraregionaltransactionintheU.S.andCanada

regions.

Formoreinformation,refertotheChargebackGuide.

Notes

Thefollowingnumbereditemscorrespondwiththenumbersprovidedinthe

“Notes”columninthetableabove.

1.Bestpracticeswouldsuggestthatfraudmaybeinvolved,andthemerchant

shouldprompttheconsumertotryagainoruseadifferentformof

payment.Ifthemerchantdecidestosendforauthorization,thetransaction

isnoteligiblefortheliabilityshift.

2.TheAA Vassociatedwithanattemptmustbeincludedinanysubsequent

authorizationmessage.

3.Themerchantshouldcheckthereasonfortheerrormessagebefore

decidingwhethertoproceedwiththeauthorization.Notallreasoncodes

mayindicateafailure.

MasterCardSecureCode—MerchantImplementationGuide•17June20143-15

AppendixAMerchantCustomerServiceGuide

ThissectionprovidescustomerservicestaffwithageneraloverviewoftheMasterCard®

SecureCode™service,alongwithanunderstandingoftheconsumerexperience,inorderto

provideassistancetocustomerswhenneeded.Thispublicationisdesignedforcustomer

servicestaffate-retailersthatsupportMasterCardSecureCode.

FrequentlyAskedQuestions..........................................................................................................A-1

MasterCardSecureCodeFAQs..................................................................................................A-1

CardholderEnrollmentintheMasterCardSecureCodeProgram....................................................A-4

ConsumerBuyingScenarios..........................................................................................................A-5

Authentication—Successful......................................................................................................A-6

Authentication—ForgottenSecureCode....................................................................................A-7

Authentication—Failed............................................................................................................A-8

ActivationDuringShopping(ADS)..........................................................................................A-8

ActivationDuringShopping—OptOutofEnrollment...........................................................A-10

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-i

MerchantCustomerServiceGuide

FrequentlyAskedQuestions

Amerchantshouldprovidethesefrequentlyaskedquestions(FAQs)onlineand

makethemavailabletocallcenterstaff.

NOTE

Allgraphicsinthisdocumentaresamples.Actualconsumerexperiencesmay

varybasedonthespecicimplementationbythee-retailerandthecardissuer.

Throughoutthissection,theterm“cardissuer”referstothebankornancial

institutionthatissuedtheMasterCard®cardusedbytheconsumerinthe

transaction.

MasterCardSecureCodeFAQs

FollowingareanswerstofrequentlyaskedquestionsaboutMasterCard®

SecureCode™.

QuestionAnswer

WhatisMasterCardSecureCode?Today,whenaconsumermakesapurchasefromyourwebsite,

thereisnowaytoconfirmtheconsumer’sidentity.MasterCard

SecureCodeisaservicethatprovidesamechanismforthe

consumer’sidentitytobevalidatedbythebankthatissuedthe

consumer’scard.Bydoingso,itprovidesyourbusinesswiththe

abilitytoobtainapaymentguaranteesimilartowhatisavailablein

thephysicalpoint-of-saleworld.

WhatisaSecureCode?ASecureCodeisasecretpassword,knownonlytotheconsumer,

whichisusedtovalidatetheconsumer’sidentity.Depending

upontheconsumer’sbank,theconsumermaybeaskedtoenter

their“SecureCode,”“SecureCodePassword”orsimply“Password.”

Regardless,allofthesetermsrefertothesamething.

WhatistheformatofaSecureCode?Theformatofaconsumer’sSecureCodewillvarybasedonthe

securitypolicyoftheconsumer’scard-issuingbank.Typically,

itwillbeacombinationofbetween4–10lettersandnumbers.

One-timepassword(OTP)solutionswilllikelybe6–8digits.

Whyisourwebsitesupporting

MasterCardSecureCode?

MasterCardSecureCodegivesyourwebsiteamethodtosecurely

authenticatetheidentityoftheconsumer.Intheonlineworld,

thereisnosignedsalesreceiptand,inthecaseofadisputed

purchase,itisdifficultforyoutoprovethataconsumermade

aparticularpurchase.Inthoseinstances,yourbusinessisliable

for‘unauthorizedpurchase’fraud.Byaskingaconsumerfora

SecureCode,andobtainingconfirmationfromtheconsumer’scard

issuer,yourbusinesscanobtainaguaranteeagainstcertaintypes

offraud.Inaddition,MasterCardconsumerresearchhasshown

thatconsumersaremoreconfidentshoppingatwebsitesthat

supportMasterCardSecureCode.

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-1

MerchantCustomerServiceGuide

MasterCardSecureCodeFAQs

QuestionAnswer

Howdoesourwebsitesupport

MasterCardSecureCode?

ToparticipateinMasterCardSecureCode,yourwebsitehasnew

functionalitythatworkstoconnectconsumerswiththecard

issuersothattheconsumer’sidentitycanbevalidatedeachtime

apurchaseismade.Yourwebsitegroupmayhavedecidedto

purchaseandoperateMerchantPlug-insoftwarefromanoutside

vendor.Alternatively,yourwebsitemaybecommunicating

withaserverthatrunsthesoftwareprogram.Dependingon

theimplementation,therearetimeswhenconsumersmaybe

presentedwithvendor-specificerrorcodes.Yourtechnicalsupport

staffshouldconsultwithyourvendororserviceproviderfora

listofthesecodes.

Whatisapersonalgreeting?Thepersonalgreetingisamessagethattheconsumercreateswhen

registeringforthecardissuer’sMasterCardSecureCodeprogram.

Thisisonlyapplicableforstaticpasswordimplementations.As

moreissuersmovetodynamicOTPsolutions,personalgreetings

maynolongerbepresent.Duringanonlinepurchase,thePersonal

Greetingwillappearinthepop-upboxfromthecardissuer.For

theconsumer’sassurance,thePersonalGreetingverifiesthatthe

consumeriscommunicatingwith,andsubmittingtheSecureCode

to,thecardissuer.

Whatisthedifferencebetween

authenticationandauthorization?

Authenticationistheprocessofvalidatingaconsumer’sidentity

priortocompletingthepurchase.MasterCardSecureCodeisa

cardholderauthenticationprogram.

Authorizationistheprocessofobtainingapprovalfromthecredit

cardissuingbankforaspecificpurchase.

HowdoesMasterCardSecureCode

work?

First,aconsumermustregisterandcreateaSecureCode.Eachtime

anonlinepurchaseismadeataparticipatinge-retailer,awindow

willautomaticallyappearaskingfortheSecureCode.MasterCard

requiresthiswindowtobepartoftheexistingbrowserdisplay

anddoesnotpermittheuseofpop-upwindowsforcardholder

authenticationpurposes.Theexactimplementationiscontrolled

byyourwebsite.

Afterreviewingthedetailsofthepurchaseandconfirmingthat

thePersonalGreetingiscorrect,theconsumersimplyentersthe

appropriateSecureCodetocompletethepurchase.Whenthe

consumercorrectlyenterstheSecureCode,thecardissuerconfirms

theauthorizeduserofthatcardandprovidesyourwebsitewitha

pieceofdata,calledtheaccountholderauthenticationvalue(AAV),

whichprovesthattheauthenticationwassuccessful.Thisvalue

mustbeaddedtothecreditcardauthorizationrequesttoprove

thatauthenticationwasperformed.Ifaconsumerdoesnotenter

thecorrectSecureCode,thecardissuercannotconfirmtheidentity,

andnoauthenticationtokenisprovided.Inthisparticularinstance,

theonlinemerchantshouldasktheconsumerforanalternative

formofpayment.

A-217June2014•MasterCardSecureCode—MerchantImplementationGuide

MerchantCustomerServiceGuide

MasterCardSecureCodeFAQs

QuestionAnswer

Whatisthedifferencebetweena

pop-upandaninlineauthentication

window?

TheMasterCardSecureCodeprogramisdesignedsothatthe

merchantisresponsibleforcreatingtheauthenticationwindow

andthecardissuerisresponsibleforthecontentofthiswindow.

Merchantscreateaninlinewindow,whichwillappearaspartof

thecurrentbrowsersession.MasterCardnolongerpermitstheuse

ofapop-upwindowforcardholderauthenticationbecauseofthe

prevalenceofpop-upblockingsoftware.

Howdoesourwebsiteknowifa

cardisprotectedbyMasterCard

SecureCode?

WhenaconsumerusesacardthatisenrolledinMasterCard

SecureCodeatyourwebsite,theMasterCardSecureCodesoftware

(themerchantplug-in,orMPI)automaticallymakesaninquiryto

MasterCard,whichwillcheckwiththeconsumer’scard-issuing

bank.Iftheconsumerisparticipating,thecardissuerwillopen

upasecuredialogwiththeconsumer.Thisdialogwillenable

confirmationoftheidentityoftheconsumerand,assumingthe

correctSecureCodeisentered,guaranteethepurchasetothe

merchant.

Whoknowstheconsumer’s

SecureCode?

TheSecureCodevalueisknownonlybytheconsumerandthe

consumer’scard-issuingbank.Thedialogduringwhichthe

consumerenterstheSecureCodevaluetakesplacewiththeissuing

bankonly.Nootherparties,includingyourwebsiteorMasterCard,

areinvolvedinthisprocess.Yourwebsiteissimplynotifiedofthe

resultofthisprocessviatheMasterCardSecureCodesoftware.

WhataretheConsumer’sSystem

RequirementsforMasterCard

SecureCode?

MasterCardSecureCodeworkswithmostbrowsers.Iftheconsumer

hasanydifficultyperformingauthentication,heshouldcontact

hiscardissuer’scustomerservicebycallingthephonenumber

onthebackofhiscard.

Howdoesaconsumerenrollinthe

MasterCardSecureCodeProgram?

RefertotheCardholderEnrollmentsectionforinformation.

Whatinformationiscontained

intheMasterCardSecureCode

authenticationwindow?

Theauthenticationwindowissimilartothereceiptthatconsumers

signinastore.Itincludesdetailssuchaswherethepurchaseis

beingmadeandhowmuchmoneyisbeingspent.Theactual

contentofthiswindowisprovidedbytheconsumer’scardissuing

bankbasedoninformationprovidedbyyourwebsite.

Willtheauthenticationwindow

appeariftheconsumernever

enrolledintheMasterCard

SecureCodeProgram?

Therearetwosituationswheretheauthenticationwindowmay

appear—bothofwhicharerelatedtotheenrollmentprocess.

•ASecureCodehasbeenselectedbyoneauthorizeduser

andnotcommunicatedtotheotherauthorizedusersonthe

account.Forexample,husbandandwife.Mostcardissuers

doprovidetheabilityforeachauthorizeduserofthecardto

individuallyenrollandestablishhis/herownSecureCode.In

thatcase,theSecureCodevalueforeitherusermaycomplete

theauthenticationprocess.

•ThecardissuertriestoenrolltheconsumerusingActivation

DuringShopping.RefertoActivationDuringShoppinginthis

chapterformoreinformation.ActivationDuringShopping

willonlyoccuriftheissuerhasselectedstaticpasswordas

theirauthenticationmethodforcardholders.IfadynamicOTP

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-3

MerchantCustomerServiceGuide

CardholderEnrollmentintheMasterCardSecureCodeProgram

QuestionAnswer

solutionisused,theActivationDuringShoppingstepwillnot

occur.

Whathappensiftheconsumerdoes

notknowtheirSecureCode?

Itvariesbycard-issuingbankbutconsumersareusuallygiven

threechancestosuccessfullyentertheSecureCode.Aninvalid

attemptwillresultinaprompttotheconsumertotryagain.Inthe

eventthataconsumerforgetstheSecureCode,mostcardissuers

provideanalternativemechanismtocompletetheauthentication

process.Typically,thereisa“ForgotmySecureCode”linkthatthe

consumercanclicktoobtainassistance.

Aftertheallowablenumberoftrieshasbeenexceeded,the

card-issuingbankmayprompttheconsumerwithaseriesof

questionstoauthenticatehisidentity—forexample,lastfour

digitsofsocialsecuritynumber,birthdate,signaturepanelcode

oncard,andmore.Ifthisinformationissuccessfullyvalidated,

asuccessfulauthenticationresponsewillbereturnedtoyour

website.Ifnot,theaccountwillmostlikelybelockedtoprevent

anyfurtherauthenticationattemptsatyourwebsiteandalsoat

otherparticipatingwebsites.

RefertoAuthentication—ForgottenMasterCardSecureCodeinthis

chapterforadditionalinformation.

Whathappensifauthenticationfails?Theresultofafailedauthenticationdependsonhowyour

particularwebsitehasbeensetup.Atsomewebsites,afailed

authenticationwillcausethee-retailertorequestadifferent

paymentmethodbeforeallowingthepurchasetoproceed.In

othercases,thetransactionmaybesubmittedforauthorizationas

anon-MasterCardSecureCodetransaction.

RefertoAuthentication—Failedinthischapterforadditional

information.

CardholderEnrollmentintheMasterCardSecureCode

Program

EligiblecardholdersofMasterCard®andMaestro®cardsactivateacardforuse

intheMasterCard®SecureCode™programthroughanenrollmentprocess.

Thefollowingbulletsarerelatedtotheweakerstaticpasswordauthentication

option.Thestrongerone-timepassword(OTP)authenticationapproach

requiresmuchlessscreendevelopmentandmoretimespentontheOTP

deliverymechanismandcommunication.AdditionalfeatureofRiskBased

Decisionauthenticationalsoimprovestheenrollment/authenticationapproach.

Thisprocesstypicallyoccursinoneoftwoways:

•TraditionalCardholderEnrollment—Thecardholderwillneedtogotohis

issuingbank’swebsitetoenroll,priortogoingshopping.

•ActivationDuringShopping—Thecardholderwillactivatehisaccount

duringapurchase.

A-417June2014•MasterCardSecureCode—MerchantImplementationGuide

MerchantCustomerServiceGuide

ConsumerBuyingScenarios

Itisimportanttorememberthatallenrollmentsarebetweentheauthorized

cardholdersandtheircard-issuingbanks.MasterCardisnotinvolvedinthe

enrollmentprocess.

TraditionalCardholderEnrollment

Thistypeofenrollmenttypicallytakesplaceatawebsitedesignatedbythe

bankthatissuedthecard.Forexample,itmaybethebank’shomepageor

homebankingsystem.

Inatypicalexample:

1.Theconsumerwillbeaskedtoprovideenrollmentdata.Duringthisphase

oftheprocess,theconsumerwillbeaskedaseriesofquestionstoprove

identitytotheirbank.Thismayincludeaskingforinformationsuchasthe

lastfourdigitsoftheconsumer’ssocialsecuritynumber,birthdate,orthe

signaturepanelcodefromthebackofthecreditcard.

2.Theanswerstothequestionswillbevalidatedeitherin-houseatthebank

orthroughathirdpartyprocessorsuchasacreditbureau.

3.Iftheconsumeranswersthequestionscorrectly,theconsumerisconsidered

authenticatedandwillbeallowedtoestablishtheSecureCodeforthat

particularMasterCardaccountnumber.TheSecureCodewillbestoredby

thecardissuerforuselateronduringonlinepurchasesatparticipating

e-retailers.

ActivationDuringShopping

Unlikethetraditionalenrollmentprocess,ActivationDuringShopping(ADS)

doesnotrequiretheconsumertovisitanenrollmentwebsitebeforeshopping.

Thistypeofenrollment,whichhasproventobeverysuccessful,takesplace

duringtheshoppingprocess.Whenaneligibleconsumergoestocheckout,

thecard-issuingbankwillaskaseriesofquestions—similartothetraditional

enrollmentprocess.Providingthecorrectanswerswillresultinbotha

successfulenrollmentandasuccessfulauthenticationresponsereturnedtoyour

website.RefertoConsumerBuyingScenariosinthischaptertoforasample

shoppingscenario.

ConsumerBuyingScenarios

Thissectionprovidessamplescreenshotsofconsumerscenariosthatmaybe

encounteredwhileshoppingatyourwebsite.

Thefollowingdetailsapplytoeachofthebuyingscenarioexamples.

Authentication:

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-5

MerchantCustomerServiceGuide

Authentication—Successful

•Occursaftertheconsumerelectstosubmittheorderbutprioryoursite

actuallyinitiatingarequesttoauthorizethetransaction.

•Beginsatthepointwherethee-retailerisaskingforfinalconfirmation

ofthepurchase.

Thefollowingimageisanexampleofthepointatwhichthescenariosbegin.

Actualscreencontentmayvaryfromthesamplesdepicted.

Authentication—Successful

Inthisscenario,theconsumerispresentedwiththeauthenticationwindow.

AfterenteringtheproperSecureCode,amessagewillbereturnedtoyour

websiteindicatingtheauthenticationwasperformedsuccessfully.

Atthispoint,yourwebsitewillsendthefullyauthenticatedauthorization

requesttoMasterCardforapproval.Anapprovedresponseforqualified

requestswillresultinapaymentguaranteetoyourcompany.

A-617June2014•MasterCardSecureCode—MerchantImplementationGuide

MerchantCustomerServiceGuide

Authentication—ForgottenSecureCode

Inthisscenario,usuallyassociatedwithstaticpasswordauthenticationsolutions,

theconsumerispresentedwiththeauthenticationwindow,butdoesnot

remembertheSecureCode.

InresponsetonotknowinghisorherSecureCode,theconsumerclicksForgot

YourSecureCode?ontheEnterYourSecureCodescreenandthefollowing

screenappears.

Afinancialinstitutionmaydecidetotelltheconsumerthattheymustcallthe

bank’scustomerservicedepartmentforadditionalhelpandwillreturnafailed

authenticationresponsetothemerchant.Inothercases,financialinstitutions

willprompttheconsumertoansweraseriesofsecretquestions.Providing

theproperanswertothesequestionswillpermittheconsumerauthentication

processtocompletesuccessfully.

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-7

MerchantCustomerServiceGuide

Authentication—Failed

Inthisscenario,theconsumerispresentedwiththeauthenticationwindow,

butentersanincorrectSecureCode.

Eachsubsequentattempttoenteraninvalidvaluewillresultinanerror

messageontheauthenticationwindow.

Afterapredeterminednumberofattempts,thecard-issuingbankmayoptionally

locktheaccountandpresenttheconsumerwithadisplayindicatingthat

authenticationhasfailed.Inaddition,thedisplaymaygiveinformationonhow

toobtainhelpinordertoresettheSecureCodevaluefornexttime.

Oncetheaccounthasbeenlocked,itmaynotbeusedforshoppingatany

participatinge-retailer.Theconsumermustusethefacilitiesprovidedbytheir

card-issuingfinancialinstitutiontoresettheSecureCode.Thesemayincludethe

bank’scustomerserviceand/orMasterCard®SecureCode™enrollmentsite.

ActivationDuringShopping(ADS)

Inthisscenario,associatedwithstaticpasswordauthenticationsolutions,the

consumerispresentedwiththeauthenticationwindow,buttheconsumerhas

neverenrolledintheMasterCard®SecureCode™program.

InsteadofbeingprovidedwithawindowtoentertheSecureCode,the

consumerisprovidedwithawindowtoenrollintheprogramandauthenticate

theiridentityforthecurrenttransaction.Thiswindowwilltypicallyaskaseries

ofsecretquestions.

A-817June2014•MasterCardSecureCode—MerchantImplementationGuide

MerchantCustomerServiceGuide

ActivationDuringShopping(ADS)

Ifcorrectanswersareprovidedtothequestions,themerchantwillbereturned

astatusindicatingthattheconsumerwassuccessfullyauthenticatedjustasifa

validSecureCodehadbeenentered.

Iftheincorrectresponsesareprovidedtothequestions,theconsumerwillbe

givenatleastonemoreopportunitytoprovidetheappropriateanswers.

Iftheconsumerchoosesnottoenrollintheprogramatthecurrenttime,a

messagewillbedisplayedindicatingthatthepurchasewillcontinuewithouta

SecureCodevalue.Toyourwebsite,thismeansthecreditcardauthorization

willbeunauthenticated.

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-9

MerchantCustomerServiceGuide

ActivationDuringShopping—OptOutofEnrollment

Iftheincorrectresponsesareprovidedtoomanytimes,oriftheissuer

requiresenrollmentandthecardholderdeclinestoenroll,themerchantwill

benotifiedthatconsumerauthenticationhasfailed.Inthisparticularcase,

merchantsmayeitherrequestanalternativeformofpaymentorproceedwitha

non-MasterCard®SecureCode™authorizationrequest.

ActivationDuringShopping—OptOutofEnrollment

Inthisscenario,theconsumeroptsnottoenrollintheprogramatthecurrent

time.

Insteadofprovidinganswerstothequestionsonthewindow,theconsumer

clickstheDoNotContinuelink.

A-1017June2014•MasterCardSecureCode—MerchantImplementationGuide

MerchantCustomerServiceGuide

ActivationDuringShopping—OptOutofEnrollment

Atthispointintime,thee-retailerwillbenotifiedthattheconsumerdeclined

toenrollintheprogram.Inthisparticularcase,thee-retailershouldproceed

withanunauthenticatedauthorizationusingthecurrentcardnumber.The

PAResshouldequalAandcontainanAttemptsAA V.ThisAttemptsAA Vmust

beprovidedintheAuthorizationRequest/0100messageinDE48(Additional

Data—PrivateUse),subelement43(3-DSecureforMasterCardSecureCode)

withsubelement42(ElectronicCommerceIndicators)containing211(Merchant

Onlyauthenticationtransaction[liabilityshiftapplies])fortheSecurityLevel

indicatordenotingaMerchantOnlyAuthentication.Liabilityshiftforthe

merchantisenforcedforthistypetransaction.

MasterCardrecommendsthatcardissuersgivecardholdersatleastthreechances

toenrollintheMasterCard®SecureCode™program.Ifthecardholderdoes

notenrollafterthreechances,somecardissuerswillnotgivethecardholder

theabilitytoopt-outoftheirMasterCardSecureCodeprogram,andwill,in

fact,locktheaccountandpresenttheconsumerwithadisplayindicating

thatauthenticationhasfailed.Oncetheaccounthasbeenlocked,itmay

notbeusedforshoppingatanyparticipatinge-retailer.Theconsumermust

usethefacilitiesprovidedbyhiscardissuerfinancialinstitutiontoenrollin

MasterCardSecureCode.Thesemayincludethebank’scustomerservicecenter,

itsMasterCardSecureCodeenrollmentsite,orboth.

MasterCardSecureCode—MerchantImplementationGuide•17June2014A-11

AppendixBMasterCardSecureCodeSPAAlgorithm

Specications

ThissectioncontainsthelayoutoftheAccountholderAuthenticationValue(AAV)tobe

usedbyissuersparticipatinginMasterCard®SecureCode™,aswellasanoverviewof

Base64encoding.

AAVLayout....................................................................................................................................B-1

Base64Encoding...........................................................................................................................B-1

Base64EncodingExamples.....................................................................................................B-2

Base64Alphabet......................................................................................................................B-2

MasterCardSecureCode—MerchantImplementationGuide•17June2014B-i

MasterCardSecureCodeSPAAlgorithmSpecications

AAVLayout

TheformatoftheAccountholderAuthenticationValue(AA V)isdefined

anddescribedintheSecurePaymentApplication™(SPA)Algorithmforthe

MasterCardImplementationof3-DSecurepublication.

ThisisalicensedpublicationavailableonlytoMasterCardmembersorany

non-memberthathassuccessfullyexecutedtheMasterCard®SecureCode™

licenseagreement.

Base64Encoding

ThefollowingoverviewofBase64encodingistakenfromRFC1521“MIME

(MultipurposeInternetMailExtensions)PartOne:MechanismsforSpecifying

andDescribingtheFormatofInternetMessageBodies”.

Formoredetailedinformation,openthefollowingpage:

www.ietf.org/rfc/rfc1521.txt?number=1521

Introduction

Base64encodingisdesignedtorepresentarbitrarysequencesofoctetsinaform

thatneednotbehumanlyreadable.Theencodinganddecodingalgorithms

aresimple,buttheencodeddataareconsistentlyabout33percentlargerthan

theun-encodeddata.

A65-charactersubsetofUS-ASCIIisused,enabling6bitstoberepresented

perprintablecharacter.Theextra65thcharacter,“=”,isusedtosignifya

specialprocessingfunction.

Theencodingprocessrepresents24-bitgroupsofinputbitsasoutputstrings

offourencodedcharacters.Proceedingfromlefttoright,a24-bitinputgroup

isformedbyconcatenatingthree8-bitinputgroups.These24bitsarethen

treatedasfourconcatenated6-bitgroups,eachofwhichisthentranslatedinto

asingledigitintheBase64alphabet.Whenencodingabitstreamviathe

Base64encoding,thebitstreammustbepresumedtobeorderedwiththe

most-significant-bitfirst.Thatis,thefirstbitinthestreamwillthehigh-order

bitinthefirstbyteandtheeighthbitwillbethelow-orderinthefirstbyte,

andsoon.

Each6-bitgroupisthenusedasanindexintoanarrayof64printable

characters.Thecharacterreferencedbytheindexisplacedintheoutput

string.Thesecharacters,identifiedbyBase64Alphabet.,areselectedsothat

theyareuniversallyrepresentable.Thesetexcludescharacterswithparticular

significancetoSMTP(forexample:“.”,CR,LF).

MasterCardSecureCode—MerchantImplementationGuide•17June2014B-1

MasterCardSecureCodeSPAAlgorithmSpecications

Base64EncodingExamples

ThefollowingexampleswillperformthebeginningstepsofBase64encodingof

anAccountholderAuthenticationValue(AAV)controlbytefield.Theencoding

processfortheremainderoftheAA Vwillfollowthesameprocess.

Thedecodingprocesswillsimplyworkinreverse.

AAVControlBytehexadecimal“8C”(SuccessfulCardholder

Authentication)

Displayinghexadecimal8Cinitsbinaryequivalentgivesthefollowing:

10001100

Thedataisthenbrokendownintothree24-bitsegments,whichareinterpreted

asfour6-bitsegmentsforencoding.Inthiscase,thefirst6bitsequal:

100011

Convertingthistoitsdecimalequivalentyieldsthefollowing:

(1*25)+(0*24)+(0*23)+(0*22)+(1*21)+(1*20)

32+0+0+0+2+1

Decimal35=Base64j

AAVControlBytehexadecimal“86”(AttemptedCardholder

Authentication)

Displayinghexadecimal86initsbinaryequivalentgivesthefollowing:

10000110

Thedataisthenbrokendownintothree24-bitsegments,whichareinterpreted

asfour6-bitsegmentsforencoding.Inthiscase,thefirst6bitsequal:

100001

Convertingthistoitsdecimalequivalentyieldsthefollowing:

(1*25)+(0*24)+(0*23)+(0*22)+(0*21)+(1*20)

32+0+0+0+0+1

Decimal33=Base64h

Base64Alphabet

ThefollowingistheBase64alphabetusedtoencodetheAccountholder

AuthenticationValue(A VV).

B-217June2014•MasterCardSecureCode—MerchantImplementationGuide

MasterCardSecureCodeSPAAlgorithmSpecications

Base64Alphabet

Decimal

ValueEncoding

Decimal

ValueEncoding

Decimal

ValueEncoding

Decimal

ValueEncoding

0A1B2C3D

4E5F6G7H

8I9J10K11L

12M13N14O15P

16Q17R18S19T

20U21V22W23X

24Y25Z26a27b

28c29d30e31f

32g33h34I35j

36k37l38m39n

40o41p42q43r

44s45t46u47v

48w49x50y51z

520531542553

564575586597

60861962+63/

(pad)=

MasterCardSecureCode—MerchantImplementationGuide•17June2014B-3

AppendixCMasterCardSecureCodeContactInformation

Thissectioncontainsnames,areasofresponsibility,andcontactinformationforMasterCard

personnelwhocanassistcustomerswithe-commerceenrollment,testing,and

implementationissues.

MasterCardSecureCodeContactInformation.................................................................................C-1

MasterCardSecureCode—MerchantImplementationGuide•17June2014C-i

MasterCardSecureCodeContactInformation

ThissectioncontainscontactinformationforMasterCardpersonnelwhocan

assistcustomerswithe-commerceenrollment,testing,andimplementation

issues.

AreaofResponsibilityContactInformation

CompletedandsignedenrollmentformsSendallcompletedandsignedenrollmentformsto:

securecode_customer_support@mastercard.com

Maestro®CustomerOperationsServices

U.S.,Canada,Caribbean,LatinAmerica,andSouth

Asia/MiddleEast/Africaregions

Phone:800-999-0363(InsideU.S.)

636-722-6176(OutsideU.S.)

636-722-6292(SpanishLanguageSupport)

Fax:636-722-7192

Email:securecode_customer_sup-

port@mastercard.com

Europeregion

Phone:+32-2-352-54-03

Email:css@mastercard.com

CustomerImplementationServices

Asia/Pacicregion

Email:cis_ap_support@mastercard.com

MiddleEast/Africaregion

Email:cis_mea_support@mastercard.com

Europeregion

Email:cis_europe_support@mastercard.com

CanadaandU.S.regions

Email:cis_northamerica_support@mastercard.com

LatinAmericaandtheCaribbeanregion

Email:cis_lac_support@mastercard.com

ProgramManagementSupport

Pricing/Billing

securecode_customer_support@mastercard.com

Supportsecurecode_customer_support@mastercard.com

MasterCardSecureCodeOnlineResources

ForadditionalinformationaboutMasterCard®SecureCode™,visitoneofthe

followingwebsites:

MasterCardSecureCode—MerchantImplementationGuide•17June2014C-1

MasterCardSecureCodeContactInformation

•MasterCardSecurityResources

•MasterCardSecureCode360Webinars

•ConsumerWebsite

•MasterCardSecureCodeVendorList

•MasterCardSecureCodeFrequentlyAskedQuestions

•MerchantWebsite

–MerchantFrequentlyAskedQuestions

–ProgramIdentifierGuidelines

AdditionalreferencesareavailableonMasterCardConnect™inEnglish,

Spanish,andPortugueseunderLibrary>Publications>SecureCode.

C-217June2014•MasterCardSecureCode—MerchantImplementationGuide

AppendixDMaestroProcessingConsiderations

Thissectioncontainsdetailedinformationaboutspecicprocessingissuesassociatedwith

Maestro®andMasterCard®SecureCode™.Merchantsshouldcontacttheiracquirerfor

specicauthorizationandclearingrequirements.

AccountinGoodStanding............................................................................................................D-1

MasterCardSecureCode—MerchantImplementationGuide•17June2014D-i

MaestroProcessingConsiderations

AccountinGoodStanding

Anaccountingoodstandingtransactionisarequestbyamerchanttocheck

theauthenticityofaMaestro®accountnumber.

UnlikeotherMaestrotransactions,AccountinGoodStandingisnotafinancial

transaction.Itdoesnotperformavaluecheckorguaranteethatthecustomer

hassufficientfundstocoverthepurchase.Theobjectiveistosatisfythe

merchant’sprimaryconcerntoensurethattheMaestrocardnumberbeing

providedbythecustomerisnotcounterfeit.

MerchantsmustnotconfuseanAccountinGoodStandingtransactionwitha

pre-authorizationtransactionusedforself-servicepumpsatpetrol/gasstations.

Thesetransactionsareusedtoguaranteeablockoffundsuptotheamount

inthetransaction,provideditisfollowedwithin20minutesbyacompletion

transaction.

Anaccountingoodstandingtransactionisastandardauthorizationmessage

withthefollowingspecificdatacontentrequirements.

DataElementValue

DE4(Amount,Transaction)Oneunitofpurchasecurrency

DE61(Point-of-Service[POS]Data),

subfield7(POSTransactionStatus)

4=PreauthorizedRequest

ThesedataelementsmustbeusedbytheacquirerwhenplacinganAccount

inGoodStandingtransactions.Eachacquirerisresponsiblefordetermining

howthistransactionissupportedinthepointofinteractionmessagedefined

forthemerchanttoacquirerinterface.

ForCredit,thereistheAccountStatusInquiry,whichisanon-financialrequest

thatallowsacquirerstovalidateaspectsofthecardholderaccount.SomeACS

providerswillalsousethismessagetoverifycardholderenrollmentsuchas

CVC,A VC,andexpirydate.AdditionaldetailscanbefoundintheCustomer

InterfaceSpecificationmanual.

DataElementValue

DE3(ProcessingCode)00=Purchase

DE4(Amount,Transaction)Mustbezero

DE48(AdditionalData—PrivateUse),

subelement82(AddressVerification

ServiceRequest)

52=AVSandauthorizationRequest0100

DE48(AdditionalData—PrivateUse),

subelement92(CVC2)

CVC2fromsignaturepanelifapplicable

DE61(Point-of-Service[POS]Data),

subfield7(POSTransactionStatus)

8=AccountStatusInquiryService

MasterCardSecureCode—MerchantImplementationGuide•17June2014D-1

AppendixEIndiaIVRTransations(SecureTelephone)

ThissectionprovidesanoverviewoftheMasterCardrequirementstosupportIVR

TransactionsinIndia.

Overview.......................................................................................................................................E-1

DataExtensionstotheExisting3-DSecureProtocol.....................................................................E-1

UCAFTransportinMasterCardAuthorizationMessages................................................................E-1

MasterCardSecureCode—SecurityLevelIndicator(DE48,subelement42)............................E-2

UniversalCardholderAuthenticationField(DE48,subelement43)........................................E-3

WhatisanAAV?.......................................................................................................................E-3

SampleIVRTransactionFlow..................................................................................................E-4

MasterCardSecureCodeComplianceandFunctionalTesting..................................................E-4

MasterCardSecureCode—MerchantImplementationGuide•17June2014E-i

IndiaIVRTransations(SecureT elephone)

Overview

Followingthesuccessfuldeploymentof3-DSecure(SecureCode)forall

domesticelectroniccommercetransactions,thebankingauthorityofIndia,

ReserveBankofIndia(RBI),hasdefinedamandatethatrequiresasimilar

two-factorauthenticationprocesstoalsoberolledoutforIVRtransactions.

AstherewasnotechnologyorprecedentofauthenticatinganIVRtransaction

withtwo-factorauthentication,MasterCardhasworkedwithIVRvendorsto

utilizeexistinginvestmentsintechnology,processandinfrastructuretobuilda

frameworkandspecificationusingthe3-DSecureprotocol.Asownerofthe

3-DSecureProtocol,Visahaspublishedacountry-specific(India)specification

thatdefinesanumberofadditionaldataelementsintheexisting3-DSecure

messages.

Formoreinformation,refertotheVisadocument3-DSecureFunctional

Requirements—ExtensionsforMobileandIVRTransactionsinIndiav1.1.

DataExtensionstotheExisting3-DSecureProtocol

Asdetailedinthe3-DSecureFunctionalRequirements—ExtensionsforMobile

andIVRTransactionsinIndiav1.1,theVerifyEnrollmentRequest(VEReq),

VerifyEnrollmentResponse(VERes),andPAReqmessagingwithinthe3-D

SecureprotocolhavebeenextendedtoallowtheMerchantplug-in(MPI)

andIssuerAccessControlServer(ACS)toconveytheadditionaltransaction

relatedelementsthatidentifyanIVRtransaction,asopposedtoanelectronic

commercetransaction.

UCAFTransportinMasterCardAuthorizationMessages

MasterCardhasdesignatedspecificsubelementswithinDE61(Point-of-Service

[POS]Data)andDE48(AdditionalData–PrivateUse)fortheidentificationof

SecureTelephoneOrderandtransportofUniversalCardholderAuthentication

Field™(UCAF)-relateddataandassociatedindicatorsinauthorizationmessages.

ThesesubelementswillbeusedtosupportandidentifyIVRtransactionswithin

theauthorizationmessage.SupportforSecureTelephoneOrderwithinthe

authorizationmessagewasmandatedaspartofthe7.2Banknetrelease.

Thesubelementsaredescribedinthefollowingsections.Refertothe

CustomerInterfaceSpecificationmanualforadditionalinformationregarding

authorizationmessageformatting.

SecureTelephone—DE61—Point-of-Service(POS)Data,subelements4,7,

and10.ThefollowingsubelementvaluesaretocorrectlyidentifyanIVR

(SecureTelephoneOrder)DE61.

MasterCardSecureCode—MerchantImplementationGuide•17June2014E-1

IndiaIVRTransations(SecureT elephone)

MasterCardSecureCode—SecurityLevelIndicator(DE48,subelement42)

PositionValueDescription

4—POSCardholder

Presence

3CardholderNotPresent,Phone/ARUOrder

7—POSTransaction

Status

2SecureCodePhoneOrder

10—Cardholder-

ActivatedTerminal

Level

MUST

NOT

BE6

AuthorizedLevel6CAT:ElectronicCommerce

MasterCardSecureCode—SecurityLevelIndicator(DE48,

subelement42)

TheSecureCodeSecurityLevelIndicatorcontainsthefieldsrepresenting

thesecurityprotocolandcardholderauthenticationtypeassociatedwiththe

transaction.

MasterCardrequiresthatDE48(AdditionalData—PrivateUse),subelement42

(ElectronicCommerceIndicators)beincludedandproperlypopulatedforall

electroniccommerceandSecureTelephone(IVR)transactionauthorizations.

PleasenotethatonlyFullyauthenticatedIVRtransactions(SecurityLevel

Indicator2[UCAFdatacollectionissupportedbythemerchant,andUniversal

CardholderAuthenticationField™{UCAF}dataispresentinDE48,subelement

43[UniversalCardholderAuthenticationField{UCAF}])areapplicableto

SecureTelephoneorder(IVR)transactions.

TherequiredDE48(AdditionalData—PrivateUse),subelement42(Electronic

CommerceIndicators),subfield1(ElectronicCommerceSecurityLevelIndicator

andUCAFCollectionIndicator)valuesforSecureTelephoneorder(IVR)are

providedinthetablebelow.

PositionValueDescription

1—SecurityProtocol2Channel

2—Cardholder

Authentication

1Cardholdercertificatenotused

0UCAFdatacollectionisnotsupportedbythe

merchant

1UCAFdatacollectionissupportedbythemerchant,

andUCAFdatamaybeavailable(DE48,subelement

43maybepresentforMasterCardSecureCode)

3—UCAFCollection

Indicator

2UCAFdatacollectionissupportedbythemerchant,

andUCAFdatamustbepresent(DE48,subelement

43)

E-217June2014•MasterCardSecureCode—MerchantImplementationGuide

IndiaIVRTransations(SecureT elephone)

UniversalCardholderAuthenticationField(DE48,subelement43)

UniversalCardholderAuthenticationField(DE48,subelement

43)

TheUniversalCardholderAuthenticationField™(UCAF)containstheencoded

MasterCard®SecureCode™issuer-generatedauthenticationdata(collectedby

themerchant)resultingfromallMasterCardSecureCodefullyauthenticated

transactions.

UCAFisastandard,globallyinteroperablemethodofcollectingcardholder

authenticationdataatthepointofinteraction.WithintheMasterCard

authorizationnetworks,UCAFisauniversal,multipurposedatatransport

infrastructurethatisusedtocommunicateauthenticationinformationbetween

cardholders,merchants,issuers,andacquirers.Itisavariablelength(maximum

32characters)fieldwithaflexibledatastructurethatcanbetailoredtosupport

theneedsofissuersecurityandauthenticationapproaches.

NOTE

Allacquirersandissuersmustensurethattheycansendand/orreceivecontents

inthiselduptothemaximumlengthof32.Notethatapplicationsutilizing

thiseld,suchasMasterCardSecureCode,mayprovidecontentsthatareless

thanthemaximumlength.ForMasterCardSecureCodespecically,thiseld

willbe28positions.ThiseldshouldNOTincludeanypaddingtomeetthe

maximumlengthof32bytes.

WhatisanAAV?

TheAccountholderAuthenticationValue(AAV)isaMasterCard®SecureCode™

specifictokenthatusestheUniversalCardholderAuthenticationField™(UCAF)

fieldfortransportwithinMasterCardauthorizationmessages.

Itisgeneratedbytheissuerandpresentedtothemerchantforplacementin

theauthorizationrequest.ThisAA Vcanbeproofofafullyauthenticatedoran

attemptedauthenticationtransaction.

Inthecaseofachargebackorotherpotentialdisputeprocessing,theAAVis

usedtoidentifytheprocessingparametersassociatedwiththetransaction.

Amongotherthings,thefieldvalueswillidentifythe:

•IssuerACSthatcreatedtheAAV.(ThiscouldbetheIssuerACSor,inthe

caseofanattempt,theMasterCardAttemptprocessingserver.)

•Sequencenumberthatcanpositivelyidentifythetransactionforthatlocation

•SecretkeyusedtocreatetheMessageAuthenticationCode(MAC),which

isacryptographicmethodthatensuresAAVdataintegrity,andbindsthe

entireAAVstructuretoaspecificPAN.

UCAFisthemechanismthatisusedtotransmittheAA Vfromthemerchantto

issuerforauthenticationpurposesduringtheauthorizationprocess.

MasterCardSecureCode—MerchantImplementationGuide•17June2014E-3

IndiaIVRTransations(SecureT elephone)

SampleIVRTransactionFlow

AnexampleofaSecureTelephoneorder(IVR)transactionisasfollows.

1.Cardholdercallsthemerchanttoorderitems,andfinalizepurchase.

2.Merchantcollectsallnecessarydata,includingthecardholder’sprimary

accountnumber(PAN)andphoneinformation.

3.Themerchant’smodifiedIVR-MPIcreatesaVerifyEnrollmentRequest

(VEReq)messagewiththeIVRextensions,includingthefollowingdata:

a.FormatofPhonenumberorDeviceID

b.CardholderPhonenumberorDeviceID

c.PAReqchannel—DIRECT

d.ShoppingChannel—IVR

e.AvailableAuthenticationChannels

4.TheMasterCardDirectoryServerwillforwardtheVEReqmessagetothe

appropriateIssuerIVR-ACS,tovalidatethatthePANisenrolledinthe

service.

5.TheissuerIVR-ACSrespondstotheMasterCardDirectorywithconfirmation

ofenrollmentandtheVerifyEnrollmentResponse(VERes)message

includingtheACSwebaddressisreturnedtotheMerchantIVR-MPI.

6.IVR-MPIgeneratesaPAReqmessagewiththeIVRextension,andsends

totheappropriateIssuerIVR-ACS.

7.ACSreceivesandprocessesthePAReqmessage—IVRextensionsmaybe

usedbytheIssuerACSintheauthenticationprocess.

8.Uponsuccessfulvalidationofthecardholder(orusingdatacontainedin

theextendedPAReq),theissuerACSwillgeneratethePAResmessageand

forwardtoMerchantIVR-MPI.

9.IVR-MPIreceivesPAResandproceedswithauthorizationrequest.

MasterCardSecureCodeComplianceandFunctionalTesting

MasterCardhasdevelopedvendorcompliancetesting,aswellasissuerand

merchantfunctionaltesting,toensurevendorproductsandmemberand

merchantimplementationsarecompliantandsuccessfullyinteroperatewithall

MasterCard®SecureCode™platformsandinfrastructure.

Allvendors,merchantendpoints,andissuersarerequiredtocompletethe

designatedtestingprocesspriortolaunch.Moreinformationregardingtesting

isavailablefromsecurecode_customer_support@mastercard.com.

E-417June2014•MasterCardSecureCode—MerchantImplementationGuide

AppendixFMasterCardAdvanceRegistrationProgram

Requirements

ThissectionintroducestheMasterCardAdvanceRegistrationProgram(MARP)and

identiestheprogramrequirements.

MasterCardAdvanceRegistrationProgram....................................................................................F-1

MARPMerchantUseofMasterCardSecureCode............................................................................F-1

IssuerParticipationinMARP..........................................................................................................F-2

MasterCardSecureCode—MerchantImplementationGuide•17June2014F-i

MasterCardAdvanceRegistrationProgramRequirements

MasterCardAdvanceRegistrationProgram

TheMasterCardAdvanceRegistrationProgram(MARP)wasintroducedfor

Maestro®in2008,andforMasterCardin2010.

NOTE

MARPisclosedtonewbusinessandwillbedecommissioned1June2015.For

moredetails,refertoEuropeRegionOperationsBulletinNo.2,3February2014.

MARPMerchantUseofMasterCardSecureCode

TheMasterCardAdvanceRegistrationProgram(MARP)enablesenrolled

merchantstoauthenticatee-commercetransactions.

NOTE

NonewmerchantsareallowedtoenrollinMARP .Effective30April2014,

MasterCardwillbewithdrawingMARP .Formoredetails,refertotheEurope

RegionOperationsBulletinNo.2,3February2014.

•Themerchantinvitesthecustomertoregisteronitswebsitebychoosinga

usernameandpassword,orsimilarcredentialsacceptabletoMasterCard,

andmustprovidethecustomerwiththeoptiontoregisteraMasterCard®or

Maestro®cardaccountnumberforuseinfuturee-commercetransactions.

•ForthefirstMasterCardorMaestroe-commercetransaction,themerchant

mustrequestMasterCard®SecureCode™authenticationbeforesubmitting

thetransactionforauthorization.Ifthattransactionissubsequently

authorizedbytheissuer,itisguaranteedtotheacquireroritsmerchant,

regardlessofwhethertheissuerorcardholderparticipatesinMasterCard

SecureCodeasdeterminedbythemerchantrequest.

•IfthefirstMasterCardorMaestroe-commercetransactionforthecardholder

registeredwiththemerchantisauthorizedbytheissuer,themerchantcan

skiptheMasterCardSecureCodeauthenticationonsubsequenttransactions

bythesamecustomerusingthesameMasterCardorMaestrocardaccount.

Inthatcase,themerchantwillpopulate:

–DataElement(DE)48,(AdditionalDataPrivateUse,subelement32

(MasterCardAssignedID)intheAuthorizationRequest/0100message

withanIDassignedbyMasterCard.

–DE48,subelement43(3-DSecureforMasterCardSecureCode)inthe

AuthorizationRequest/0100messagewithaMasterCard-assignedstatic

AccountAuthenticationValue(AA V).

–DE48,subelement42,position3(UCAFCollectionIndicator)inthe

AuthorizationRequest/0100messagewithavalueof3.

–Privatedatasubelement0052(ElectronicCommerceSecurityLevel

Indicator)subfield3(UCAFCollectionIndicator)intheclearingrecord

submittedtoGCMSforprocessing(whereapplicable)withavalueof3.

MasterCardSecureCode—MerchantImplementationGuide•17June2014F-1

MasterCardAdvanceRegistrationProgramRequirements

IssuerParticipationinMARP

–ThePDS176(MasterCardAssignedID)intheclearingrecordsubmitted

toGCMSforprocessingwithanIDassignedbyMasterCard.

•IfthemerchantpopulatestheUniversalCardholderAuthenticationField™

(UCAF)withthestaticAAVassignedbyMasterCard,andpopulatesthe

UCAFCollectionIndicatorwiththevalueof3,andtheissuerauthorizes

thetransaction,theissuerwillhavearighttochargebackthetransaction

forreasonoffraud.

•IfaregisteredcardholderusesadifferentMasterCardorMaestro

cardaccountnumberforatransaction,themerchantmustrequest

MasterCardSecureCodeauthenticationbeforesubmittingthetransaction

forauthorization.

•Basedonariskassessment,themerchantalwayshastheoptionof

requestingMasterCardSecureCodeauthenticationforanyMasterCardor

Maestrotransaction,inwhichcasethetransactionwillbegovernedby

existingMasterCardSecureCodeandChargebackrules.Forinstance,

forconsumercardsacquiredintheEuroperegion,ifthetransactionis

subsequentlyauthorizedbytheissuer,itisguaranteedtotheacquireror

itsmerchant,regardlessofwhethertheissuerorcardholderparticipatesin

MasterCardSecureCodeasdeterminedbythemerchantrequest.

IssuerParticipationinMARP

AnyMaestro®issuerthatsupportse-commerceisrequiredtosupportthestatic

AccountholderAuthenticationValue(AA V)inauthorizationuntil1June2015,

atwhichtimeMasterCardwilldiscontinuetheMaestroAdvanceRegistration

Program(MARP).Formoredetails,refertoEuropeRegionOperationsBulletin

No.2,3February2014.

IssuersmustmeetexistingEuroperegionrequirementstosupportMaestro

e-commercetransactions.

RequirementscanbefoundintheAuthorizationManualand,ifapplicable,

theGCMSReferenceManualavailableonthePublicationspageonMasterCard

Connect™.

F-217June2014•MasterCardSecureCode—MerchantImplementationGuide

AppendixGMasterCardExtensionsfortheBrazilMarket

ThissectionprovidesspecicationsrelatedtoextensionsthatsupportBrazildomestic

processing.Theseextensionsallowpassingofdatafromthemerchanttotheissuerin3-D

Securemessages.

BrazilMarketExtensions...............................................................................................................G-1

MasterCardSecureCode—MerchantImplementationGuide•17June2014G-i

MasterCardExtensionsfortheBrazilMarket

BrazilMarketExtensions

ThissectionprovidesspecificationsrelatedtoextensionsthatsupportBrazil

domesticprocessing.Theseextensionsallowpassingofdatafromthemerchant

totheissuerin3-DSecuremessages.

TheseextensionswillbeusedinboththeVEReqandPAReqmessages.

•CardAccountType

•MobilePhoneNumber

•MerchantCategoryCode

•TransactionType

TheVEReqandPAReqareextendedtoallowtheMerchantPlugIn(MPI)to

passtheadditionaltransaction-relatedelementstotheAccessControlServer

(ACS)specifiedbelow.

FieldDenitionsforBrazilMarketExtensionsinVEReqandPAReq

ElementNameDescriptionFormatandValues

ExtensionIdvisa.3ds.brazil_market

brazilmccMerchantCategory

Code,providedbythe

merchant

Length1–4,Numericdigits

brazilaccounttypeAccountTypeasselected

bythecardholderduring

checkout.

Length1–2,Numericdigits

•00(NOTAPPLICABLE)

•01(CREDIT)

•02(DEBIT)

brazilmobilenumberMobilenumber(asentered

bythecardholderduring

checkout)

Length1–25,Numericdigits

braziltransactiontypeTransactionType,provided

bythemerchant

Length1–2;NumericDigit

•00(Goods/ServicePurchase)

•03(CheckAcceptance)

•10(AccountFunding)

•11(Quasi-CashTransaction)

•28(PrepaidActivation&Load)

NOTE

Thecriticalattributemustbesetto“false”forallExtensioneldsdenedin

thisprotocolextensionspecication.

MasterCardSecureCode—MerchantImplementationGuide•17June2014G-1

MasterCardExtensionsfortheBrazilMarket

BrazilMarketExtensions

MessageSampleofBrazilMarketExtensionsinVEReq

MessageSampleofBrazilMarketExtensionsinPAReq

G-217June2014•MasterCardSecureCode—MerchantImplementationGuide

MasterCard SecureCode SMI Manual Merchant

Navigation menu

Versions of this User Manual:

Views

Navigation