How to get access to Direct Payment API?

[mikewz]

Hi,

Wondering if @MTS_Christina, @MTS_Ciaran  or @MTS_Justin can help with the below:

Please can you advise how we might arrange access for our PayPal account to the PayPal Direct Payment API (as outlined at https://developer.paypal.com/docs/classic/paypal-payments-pro/integration-guide/direct-payment)?

We are attempting to access this API from an existing PayPal account in order to fulfil our commitment to 3D Secure integration, but currently when trying to access the API we receive the following error message:

[L_ERRORCODE] => 10548
[L_SHORTMESSAGE] => Invalid Configuration
[L_LONGMESSAGE] => This transaction cannot be processed. The merchant's account is not able to process transactions.

This implies that our UK PayPal business account is not configured to allow access to this API.

We have tried emailing <removed> but so far have not had any response on this question.

Thanks.

[angelleye]

I have had quite a bit of confusing around this as well trying to get it fully supported in our PayPal for WooCommerce plugin.  The information we have gotten is that it's not yet ready for PayFlow.

I've been recommending that people switch to Braintree.  Using that with the Drop-In UI will help take care of 3DS stuff and will also provide a better checkout experience as it includes PayPal, direct credit cards, Google Pay, Apple Pay, and Venmo all in a single hosted checkout integration.

[Payflow_Todd]

@mikewz 

Basically, Payflow has always supported 3rd Party MPI's as well as having its own Buyer Authentication Service. All the details for sending data via Payflow when using a 3rd party MPI; i.e. Cardinal Commerce, is in the Buyer Authentication guide. However, it's confusing so I am in the process of having the Payflow Gateway Developer Guide updated with a new Appendix related to 3DS support.  Should be out soon.

But basically, if you are using Cardinal, you'll do the authorization via Cardinal and send the data received in the Sale or Authorization request.

The cardholder is enrolled:

• AUTHENTICATION_ID - Unique identifier for this authentication validation. AN (64)
• AUTHENTICATION_STATUS – Value returned by MPI indicating if authentication was successful, attempted or failed. N(1)
• CAVV - Cardholder authentication verification value, also known as AAV. The value generated by the card-issuing bank proving the cardholder has been authenticated with a particular transaction. Returned if the AUTHENTICATION_STATUS is Successful or Attempted. AN(64)
• ECI - E-Commerce Indicator. The ECI value indicates the level of security supported by the merchant when the cardholder provides payment card data for online purchase. N(1)
• XID – 3D-Secure transaction ID. Returned if Successful or Attempted.  Required, AN (64)

NOTE: The following two fields will be supported in the future, starting with PayPal in September and other processors to follow.  You can send these fields now, but they won’t be effective until support is added.

• THREEDSVERSON – Contains the 3DS version that was used to process the transaction.
  Possible values: 1.0.2, 2.1.0 and 2.2.0. Default = 1.0.2. AN (10)
• DSTRANSACTIONID – Unique transaction identifier assigned by the Directory Server (DS) to identify a single transaction. Note: Required for MasterCard Identity Check transaction in Authorization.  Conditional, AN (36)

Example:
VENDOR=MerchantUserID&PARTNER=PayPal&USER=UserIDIfAvailOrSameAsVendor&PWD=Pwd4Payflow&TENDER=C&TRXTYPE=S&TENDER=C&ACCT=5555555555554444&EXPDATE=0308&AMT=123.00&AUTHENTICATION_ID[20]=8d4d5ed66ac6e6faac6d&CAVV[28]=OTJlMzViODhiOTllMjBhYmVkMGU=&AUTHENTICATION_STATUS[1]=1&ECI[1]=5&XID[28]=YjM0YTkwNGFkZTI5YmZmZWE1ZmY&THREEDSVERSION[5]=1.0.2

The cardholder is not enrolled; see descriptions above:

• AUTHENTICATION_ID
• AUTHENTICATION_STATUS
• ECI

Note: the following field will be supported in the future, starting with PayPal in September and other processors to follow.  You can send this field now, but it won’t be effective until support is added.

• THREEDSVERSION

Example:
VENDOR=MerchantUserID&PARTNER=PayPal&USER=UserIDIfAvailOrSameAsVendor&PWD=Pwd4Payflow&TENDER=C&TRXTYPE=S&ACCT=5555555555554444&EXPDATE=0308&AMT=123.00&AUTHENTICATION_ID[20]=8d4d5ed66ac6e6faac6d&AUTHENTICATION_STATUS[1]=O&ECI[1]=7&THREEDSVERSION[5]=1.0.2

Let me know if you have any other questions.

Todd

[mikewz]

Thanks for taking the time to clarify this in such detail @Payflow_Todd, it's super helpful to know these details in advance.

Based on your comment I just had a few questions:

1. All the fields seem clear, apart from the AUTHENTICATION_ID - I couldn't marry this up with an equivalent field in the 3DS integration guide. In the case of Cardinal this looks like it could be any one of 3 different values they return - ProcessorTransactionId (present in responses to both v1.0.2 and v2.2.0) or ACSTransactionId or ThreeDSServerTransactionId (only present in v2.2.0). Can you advise which we should use?
   
   
2. Our understanding at this time is that 3DS 2 is only in play for a European merchant and a European issued card. Is that correct?
   
   
3. If so, would we need to pass the "cardholder not enrolled" values for non-European cards - e.g. a European merchant with a U.S. issued card?
   

Thanks,

Mike.

[angelleye]

Here is a sample I got from another PayPal rep that he says is working, but I have not yet played with it myself.

https://github.com/mikaey/paypal-3ds-example/blob/master/payflow/ajax.php

[Payflow_Todd]

@mikewz 

1.  Payflow supports both BYOB (Bring your own Bank) and PayPal as your bank.   Not all fields map to all processors or PayPal.  It looks like PayPal doesn't support this parameter, so you can ignore it.   However, I believe AUTHENTICATION_ID would map to ProcessorTransactionId as only v1.x was supported and for v2.x support right now only DSTransactionId and the version is supported.   Payflow (Buyer Authentication Service) was based on older Cardinal Centinel service and we'll be updating it in the future to support Cardinal Cruise.

2. Correct, 3DS 2.0 is an EU requirement at this time.  The US will catch up at some point in the near future.

3. The US card could be registered, so you'd treat these the same regardless of where the merchant is located.  However, for US card you won't get full v2 support.

[mikewz]

@not_here @Payflow_Todd - Following on from your assistance last month, is Payflow support for 3DS available yet? We are keen to integrate into our environment so that we can test before 14th September.

If it is, where would be the best place to look for documentation, and if it is not are there any timeframes for when it is expected to be available for merchants?

Thanks.

[not_here]

Hi @mikewz,

We have published the documentation 3-D Secure with 3rd Party Merchant Plug-ins. Please let me know if this helps or if you have additional questions.

Thanks,
Christina