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
- 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
- Appendix C MasterCard SecureCode Contact Information
- Appendix D Maestro Processing Considerations
- Appendix E India IVR Transations (SecureTelephone)
- Appendix F MasterCard Advance Registration Program Requirements
- Appendix G MasterCard Extensions for the Brazil Market
![](asset-1.png)
MasterCardSecureCode
MerchantImplementationGuide
17June2014
![](asset-2.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
SMI17June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-3.png)
SummaryofChanges,17June2014
Thisdocumentreflectschangeseffectivesincethelastpublicationofthismanual.
DescriptionofChangeWheretoLook
AddednotesindicatingthatboththeMasterCardAdvanceRegistration
ProgramandMaestroAdvanceRegistrationProgram(MARP)areclosedto
newbusinessandwillbedecommissionedon1June2015.
Throughoutdocument
AddedreferencestotheMasterCardAttemptsProcessingServiceandthe
MasterCardAuthenticationHistoryServer.
Throughoutdocument
AddednewappendixtoprovideanoverviewoftheMasterCard
requirementstosupportIVRTransactionsinIndia.
IndiaIVRTransations
(SecureTelephone)
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20141
![](asset-4.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•3January20141
![](asset-5.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014i
![](asset-6.png)
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
Specications............................................................................................B-i
AAVLayout..............................................................................................................................B-1
Base64Encoding.....................................................................................................................B-1
Base64EncodingExamples...............................................................................................B-2
Base64Alphabet................................................................................................................B-2
©2005–2014MasterCard.Proprietary.Allrightsreserved.
ii17June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-7.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014iii
![](asset-8.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20141-i
![](asset-9.png)
SecureCodeMerchantImplementationOverview
MasterCardandE-commerce
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20141-1
![](asset-a.png)
SecureCodeMerchantImplementationOverview
GrowYourOnlineBusiness
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
1-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-b.png)
SecureCodeMerchantImplementationOverview
MasterCardSecureCodeProgramPlatform
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20141-3
![](asset-c.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
1-417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-d.png)
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
IfaretailerhasqualiedandacceptedamerchantfortheMasterCardAdvance
RegistrationProgram(MARP),thenMasterCardwillassignastaticAccountholder
AuthenticationValue(AAV)forusewhenthetransactionisundertakenas
MARPinsteadofstandardMasterCardSecureCode.Thisvalueispassedin
plaintextintheUniversalCardholderAuthenticationField™(UCAF)eld.For
additionalinformation,refertotheMasterCardAdvanceRegistrationProgram
Requirementsappendix.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20141-5
![](asset-e.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-i
![](asset-f.png)
3-DSecureSolution
3-DSecureSolutionOverview
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-1
![](asset-10.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
2-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-11.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-3
![](asset-12.png)
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.
CerticateAuthority
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
2-417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-13.png)
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.
VericationRequest/Response
MessagePair:VEReq/VERes—Thefirststepinthepayerauthenticationprocess
istovalidatethatthecardholderaccountnumberispartofanissuer’scard
range,whichisparticipatingin3-DSecure.
TheVerificationRequest/ResponsemessagesaresentfromtheMerchantServer
Plug-IntotheDirectorytocheckcardrangeeligibility.Ifthespecifiedaccount
numberiscontainedwithinaMasterCard®SecureCode™eligiblecardrange,
thismessageisthensentfromtheDirectorytotheAccessControlServer(ACS)
tocheckifthespecificaccountnumberisenrolledandactivetoparticipatein
3-DSecure.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-5
![](asset-14.png)
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™.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
2-617June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-15.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-7
![](asset-16.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
2-817June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-17.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20142-9
![](asset-18.png)
3-DSecureSolution
CardholderAuthentication
SampleCardholderAuthenticationFlow
Thefollowingsamplecardholderauthenticationflowisidenticalforboth
MasterCardandMaestro™cardholders.
EnterPaymentInformation
Thecardholderwillshopatamerchantlocationjustastheywouldtoday.
Afterselectingtheitemstobeplacedintotheshoppingcart,thepaymentcard
informationtobeusedforthetransactionisentered.
ConrmandSubmitOrder
Onceallofthepaymentandshippinginformationhasbeenentered,the
cardholderistypicallygivenanopportunitytoreviewthepurchaseonelast
timebeforesubmittingtheorder.
EnterSecureCode
Uponsubmittingthefinalorder,thecardholderwillbepresentedwithan
authenticationwindowfromtheirMasterCardcardorMaestrocard-issuing
bank.Atthispoint,thecardholderwillenterhisorherSecureCodevalueto
performauthenticationprocessing.
PurchaseCompleted
AftervalidationofthecardholderSecureCodebytheissuingbank,the
authenticationwindowwilldisappearandtheauthorizationofthepayment
cardwillcompleteasusual.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
2-1017June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-19.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-i
![](asset-1a.png)
Merchants
Overview
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™.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-1
![](asset-1b.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-1c.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-3
![](asset-1d.png)
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.
01
NCardholderauthenticationfailedSLI=0Absent
UAuthenticationcouldnotbecompletedduetotechnical
orotherproblems(SLI=1)
Absent
NOTE
PAResstatusmustcorrelatewiththeECIandSecurityLevelIndicatorchart
shownintheProcessingMaxtrix.TheECIvalueandSecurityLevelIndicator
passedaspartoftheAuthorizationRequest/0100messagearedifferentvalues
andaredenotedintheProcessingMatrix.
NOTE
MasterCardhasadditionaldenitionsofSLIsthatarenotgeneratedbythe
PAResreceivedbutthatmayneedtobeusedbythemerchant.Refertothe
MerchantProcessingMatrixsectionforadditionalinformationonSLIs.(SLI)
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-1e.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-5
![](asset-1f.png)
Merchants
Customization
Customization
Followingaremerchantrequirementsforcustomizingorconfiguringvendor
productsinsupportofMasterCard®SecureCode™.
MasterCardSecureCodeProgramIdentierUsageGuidelines
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-617June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-21.png)
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:
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-817June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-22.png)
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
TERMURLeldwithanHTTPSaddress.
ReplayDetection
Manyissueraccesscontrolserversattempttodetectreplayattacksbynot
allowingatransactionwiththesameaccountIDandXIDtobeprocessed
morethanonce.
MerchantsmustensurethateachPayerAuthenticationRequest(PAReq)contains
auniquecombinationofaccountIDandXID.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-9
![](asset-23.png)
Merchants
Customization
MerchantServerPlug-InConguration
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-1017June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-24.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-11
![](asset-25.png)
Merchants
Operational
2.Asdefinedbytheprotocol,theMDfieldmustalwaysbeprovided,even
ifitisnotused.
3.Ifoptionalfieldsarenotused,MasterCardrecommendstheybeexcluded
fromthemessageinsteadofusingemptydataelements.
Operational
FollowingareMasterCard®SecureCode™operationalguidelinesformerchants.
LoadingofMasterCardRootCerticates
MerchantendpointsarerequiredtoloadallactiveandpendingMasterCard
Roothierarchycertificates.
Thisrootwillberequiredbythemerchantplug-intoperformdigitalsignature
validation.ItmayalsoberequiredinordertoestablishSSLsessionsusing
certificatesbasedontheMasterCardprivatehierarchy.
NOTE
Currently,MasterCardhastwoactiverootcerticatesthatmustbeloaded.
LoadingofMasterCardSSLClientCerticate
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-1217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-26.png)
Merchants
AAVProcessing
MPIAuthenticationRequest/ResponseArchival
Merchants,ormerchantendpoints,shouldestablishapolicyforarchivalof
authenticationrequestandresponsemessages.
MasterCardrecommendsthatthearchivalperiodforthisdatabethesameasthe
associatedauthorizationtransactiondata,andshouldbeaminimumof180days.
AAVProcessing
Thefollowingprocessingstepsarerequiredbythe3-DSecureprotocoland
typicallyhandledbytheMPI.Anysubsequentprocessingistheresponsibility
ofthemerchant.
IdenticationofSPAAAVFormatinPARes
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-13
![](asset-27.png)
Merchants
MasterCardSiteDataProtectionProgram
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
3-1417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-28.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June20143-15
![](asset-29.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-i
![](asset-2a.png)
MerchantCustomerServiceGuide
FrequentlyAskedQuestions
FrequentlyAskedQuestions
Amerchantshouldprovidethesefrequentlyaskedquestions(FAQs)onlineand
makethemavailabletocallcenterstaff.
NOTE
Allgraphicsinthisdocumentaresamples.Actualconsumerexperiencesmay
varybasedonthespecicimplementationbythee-retailerandthecardissuer.
Throughoutthissection,theterm“cardissuer”referstothebankornancial
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-1
![](asset-2b.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
A-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-2c.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-3
![](asset-2d.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
A-417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-2e.png)
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:
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-5
![](asset-2f.png)
MerchantCustomerServiceGuide
Authentication—Successful
•Occursaftertheconsumerelectstosubmittheorderbutprioryoursite
actuallyinitiatingarequesttoauthorizethetransaction.
•Beginsatthepointwherethee-retailerisaskingforfinalconfirmation
ofthepurchase.
Thefollowingimageisanexampleofthepointatwhichthescenariosbegin.
Actualscreencontentmayvaryfromthesamplesdepicted.
Authentication—Successful
Inthisscenario,theconsumerispresentedwiththeauthenticationwindow.
AfterenteringtheproperSecureCode,amessagewillbereturnedtoyour
websiteindicatingtheauthenticationwasperformedsuccessfully.
Atthispoint,yourwebsitewillsendthefullyauthenticatedauthorization
requesttoMasterCardforapproval.Anapprovedresponseforqualified
requestswillresultinapaymentguaranteetoyourcompany.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
A-617June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-30.png)
MerchantCustomerServiceGuide
Authentication—ForgottenSecureCode
Authentication—ForgottenSecureCode
Inthisscenario,usuallyassociatedwithstaticpasswordauthenticationsolutions,
theconsumerispresentedwiththeauthenticationwindow,butdoesnot
remembertheSecureCode.
InresponsetonotknowinghisorherSecureCode,theconsumerclicksForgot
YourSecureCode?ontheEnterYourSecureCodescreenandthefollowing
screenappears.
Afinancialinstitutionmaydecidetotelltheconsumerthattheymustcallthe
bank’scustomerservicedepartmentforadditionalhelpandwillreturnafailed
authenticationresponsetothemerchant.Inothercases,financialinstitutions
willprompttheconsumertoansweraseriesofsecretquestions.Providing
theproperanswertothesequestionswillpermittheconsumerauthentication
processtocompletesuccessfully.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-7
![](asset-31.png)
MerchantCustomerServiceGuide
Authentication—Failed
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
A-817June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-32.png)
MerchantCustomerServiceGuide
ActivationDuringShopping(ADS)
Ifcorrectanswersareprovidedtothequestions,themerchantwillbereturned
astatusindicatingthattheconsumerwassuccessfullyauthenticatedjustasifa
validSecureCodehadbeenentered.
Iftheincorrectresponsesareprovidedtothequestions,theconsumerwillbe
givenatleastonemoreopportunitytoprovidetheappropriateanswers.
Iftheconsumerchoosesnottoenrollintheprogramatthecurrenttime,a
messagewillbedisplayedindicatingthatthepurchasewillcontinuewithouta
SecureCodevalue.Toyourwebsite,thismeansthecreditcardauthorization
willbeunauthenticated.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-9
![](asset-33.png)
MerchantCustomerServiceGuide
ActivationDuringShopping—OptOutofEnrollment
Iftheincorrectresponsesareprovidedtoomanytimes,oriftheissuer
requiresenrollmentandthecardholderdeclinestoenroll,themerchantwill
benotifiedthatconsumerauthenticationhasfailed.Inthisparticularcase,
merchantsmayeitherrequestanalternativeformofpaymentorproceedwitha
non-MasterCard®SecureCode™authorizationrequest.
ActivationDuringShopping—OptOutofEnrollment
Inthisscenario,theconsumeroptsnottoenrollintheprogramatthecurrent
time.
Insteadofprovidinganswerstothequestionsonthewindow,theconsumer
clickstheDoNotContinuelink.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
A-1017June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-34.png)
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014A-11
![](asset-35.png)
AppendixBMasterCardSecureCodeSPAAlgorithm
Specications
ThissectioncontainsthelayoutoftheAccountholderAuthenticationValue(AAV)tobe
usedbyissuersparticipatinginMasterCard®SecureCode™,aswellasanoverviewof
Base64encoding.
AAVLayout....................................................................................................................................B-1
Base64Encoding...........................................................................................................................B-1
Base64EncodingExamples.....................................................................................................B-2
Base64Alphabet......................................................................................................................B-2
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014B-i
![](asset-36.png)
MasterCardSecureCodeSPAAlgorithmSpecications
AAVLayout
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).
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014B-1
![](asset-37.png)
MasterCardSecureCodeSPAAlgorithmSpecications
Base64EncodingExamples
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).
©2005–2014MasterCard.Proprietary.Allrightsreserved.
B-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-38.png)
MasterCardSecureCodeSPAAlgorithmSpecications
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)=
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014B-3
![](asset-39.png)
AppendixCMasterCardSecureCodeContactInformation
Thissectioncontainsnames,areasofresponsibility,andcontactinformationforMasterCard
personnelwhocanassistcustomerswithe-commerceenrollment,testing,and
implementationissues.
MasterCardSecureCodeContactInformation.................................................................................C-1
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014C-i
![](asset-3a.png)
MasterCardSecureCodeContactInformation
MasterCardSecureCodeContactInformation
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/Pacicregion
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:
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014C-1
![](asset-3b.png)
MasterCardSecureCodeContactInformation
MasterCardSecureCodeContactInformation
•MasterCardSecurityResources
•MasterCardSecureCode360Webinars
•ConsumerWebsite
•MasterCardSecureCodeVendorList
•MasterCardSecureCodeFrequentlyAskedQuestions
•MerchantWebsite
–MerchantFrequentlyAskedQuestions
–ProgramIdentifierGuidelines
AdditionalreferencesareavailableonMasterCardConnect™inEnglish,
Spanish,andPortugueseunderLibrary>Publications>SecureCode.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
C-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-3c.png)
AppendixDMaestroProcessingConsiderations
Thissectioncontainsdetailedinformationaboutspecicprocessingissuesassociatedwith
Maestro®andMasterCard®SecureCode™.Merchantsshouldcontacttheiracquirerfor
specicauthorizationandclearingrequirements.
AccountinGoodStanding............................................................................................................D-1
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014D-i
![](asset-3d.png)
MaestroProcessingConsiderations
AccountinGoodStanding
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014D-1
![](asset-3e.png)
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
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014E-i
![](asset-3f.png)
IndiaIVRTransations(SecureT elephone)
Overview
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014E-1
![](asset-40.png)
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)
©2005–2014MasterCard.Proprietary.Allrightsreserved.
E-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-41.png)
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
inthiselduptothemaximumlengthof32.Notethatapplicationsutilizing
thiseld,suchasMasterCardSecureCode,mayprovidecontentsthatareless
thanthemaximumlength.ForMasterCardSecureCodespecically,thiseld
willbe28positions.ThiseldshouldNOTincludeanypaddingtomeetthe
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014E-3
![](asset-42.png)
IndiaIVRTransations(SecureT elephone)
SampleIVRTransactionFlow
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
E-417June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-43.png)
AppendixFMasterCardAdvanceRegistrationProgram
Requirements
ThissectionintroducestheMasterCardAdvanceRegistrationProgram(MARP)and
identiestheprogramrequirements.
MasterCardAdvanceRegistrationProgram....................................................................................F-1
MARPMerchantUseofMasterCardSecureCode............................................................................F-1
IssuerParticipationinMARP..........................................................................................................F-2
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014F-i
![](asset-44.png)
MasterCardAdvanceRegistrationProgramRequirements
MasterCardAdvanceRegistrationProgram
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.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014F-1
![](asset-45.png)
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™.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
F-217June2014•MasterCardSecureCode—MerchantImplementationGuide
![](asset-46.png)
AppendixGMasterCardExtensionsfortheBrazilMarket
ThissectionprovidesspecicationsrelatedtoextensionsthatsupportBrazildomestic
processing.Theseextensionsallowpassingofdatafromthemerchanttotheissuerin3-D
Securemessages.
BrazilMarketExtensions...............................................................................................................G-1
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014G-i
![](asset-47.png)
MasterCardExtensionsfortheBrazilMarket
BrazilMarketExtensions
BrazilMarketExtensions
ThissectionprovidesspecificationsrelatedtoextensionsthatsupportBrazil
domesticprocessing.Theseextensionsallowpassingofdatafromthemerchant
totheissuerin3-DSecuremessages.
TheseextensionswillbeusedinboththeVEReqandPAReqmessages.
•CardAccountType
•MobilePhoneNumber
•MerchantCategoryCode
•TransactionType
TheVEReqandPAReqareextendedtoallowtheMerchantPlugIn(MPI)to
passtheadditionaltransaction-relatedelementstotheAccessControlServer
(ACS)specifiedbelow.
FieldDenitionsforBrazilMarketExtensionsinVEReqandPAReq
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”forallExtensioneldsdenedin
thisprotocolextensionspecication.
©2005–2014MasterCard.Proprietary.Allrightsreserved.
MasterCardSecureCode—MerchantImplementationGuide•17June2014G-1