Configuring killbill-cybersource-plugin for Apple Pay

[mcas...@squaretrade.com]

Hello,

I am a newbie to Kill Bill (very cool!) and have been playing around with the Cybersource plugin. Seems to work properly in my test env as I can see test charges made in Kill Bill show up in the Cybersource test env.

I am now trying to enable Apple Pay through the Cybersource plugin. I see in the documentation (https://github.com/killbill/killbill-cybersource-plugin) that there are three Network Tokenization properties and another three labeled Apple Pay. And pierre told me:

~
In a nutshell, the following plugin properties are required:

cc_number (payment network token)
cc_exp_year / cc_exp_month (payment network token expiration date fields)
cc_type (visa, master or american_express)
payment_cryptogram (3D Secure cryptogram of the payment network token)
~

However, I have the following fields from Cybersource and I don't see how that maps to the recommendation above:
~
{
"data": "rOHDxAan<truncated>8rpI4ADg==",
"version": "EC_v1",
"header": {
"applicationData": "94e<truncated>cc2",
"transactionId": "c1caf5<truncated>60a795",
"ephemeralPublicKey": "MIIBSz<truncated>wIomw5L0=",
"publicKeyHash": "L\/moz<truncated>W1IBBY="
},
"signature": "MIIDQg<truncated>ZceA=="
}
applePayDescriptorToken=RklE<truncated>VlNRU5U
applePayTransactionType=1
applePayPaymentSolutionCode=001
~

I have tried a few different attempts and every time in the Kill Bill logs I see the XML get sent to Cybersource and the response is "soap:Client: \nXML parse error.\n" and the XML doesn't appear to have any of my Apple Pay configurations.

I think it would help if I could see a call to /1.0/kb/accounts/{accountId}/paymentMethods that is known to work. Can anyone provide one?

Any help is appreciated, thank you.

Mike

[Pierre-Alexandre Meyer]

Hi again Mike,

On Wed, Dec 14, 2016 at 12:35 PM, <mcas...@squaretrade.com> wrote:

I am a newbie to Kill Bill (very cool!)

Welcome!

 

However, I have the following fields from Cybersource and I don't see how that maps to the recommendation above:
~
{
        "data": "rOHDxAan<truncated>8rpI4ADg==",

 

This data value is the encrypted payment data. Once decrypted, you have access to the fields I was mentioning (see applicationPrimaryAccountNumber, onlinePaymentCryptogram, eciIndicator, etc.).

See https://developer.apple.com/library/content/documentation/PassKit/Reference/PaymentTokenJSON/PaymentTokenJSON.html.

http://apps.cybersource.com/library/documentation/dev_guides/apple_payments/SO_API/Apple_Pay_SO_API.pdf may be helpful too.

I think it would help if I could see a call to /1.0/kb/accounts/{accountId}/paymentMethods that is known to work.  Can anyone provide one?

In the ApplePay case, it's better to create a shell (i.e. empty) payment method associated with the card, i.e. something like (maybe add billing address or other fields if it makes sense in your case):

curl -v \

     -X POST \

     -u admin:password \

     -H 'X-Killbill-ApiKey: bob' \

     -H 'X-Killbill-ApiSecret: lazar' \

     -H 'X-Killbill-CreatedBy: admin' \

     -H 'Content-Type: application/json' \

     -d '{

       "pluginName": "killbill-cybersource",

       "pluginInfo": {

         "properties": []

       }

     }' \

     "http://127.0.0.1:8080/1.0/kb/accounts/<ACCOUNT_ID>/paymentMethods?isDefault=true&pluginProperty=skip_gw=true"

That way, you have a payment method for that account that can route to CyberSource, but you don't store any of the properties (token, etc.) because they can only be used one time.

When you trigger the actual authorization / purchase call, you can pass these ephemeral properties as such:

curl -v \

     -X POST \

     -u admin:password \

     -H 'Content-Type: application/json' \

     -H 'X-Killbill-ApiKey:bob' \

     -H 'X-Killbill-ApiSecret:lazar' \

     -H 'X-Killbill-CreatedBy: creator' \

     --data-binary '{"transactionType":"AUTHORIZE","amount":"10"}' \

     'http://127.0.0.1:8080/1.0/kb/accounts/<ACCOUNT_ID>/payments?pluginProperty=cc_number=XXX&pluginProperty=cc_type=visa&...'

In case that helps, you can take a look at the Adyen demo (we need to do something similar as some one-off data needs to be passed during the first authorization call):

  https://github.com/killbill/killbill-adyen-demo/blob/master/app.rb#L44-L47

--

Pierre

[Michael Cassano]

On Thu, Dec 15, 2016 at 3:14 AM, Pierre-Alexandre Meyer <pie...@kill-bill.org> wrote:

Hi again Mike,

On Wed, Dec 14, 2016 at 12:35 PM, <mcas...@squaretrade.com> wrote:

 

However, I have the following fields from Cybersource and I don't see how that maps to the recommendation above:
~
{
        "data": "rOHDxAan<truncated>8rpI4ADg==",

 

 

This data value is the encrypted payment data. Once decrypted, you have access to the fields I was mentioning (see applicationPrimaryAccountNumber, onlinePaymentCryptogram, eciIndicator, etc.).

See https://developer.apple.com/library/content/documentation/PassKit/Reference/PaymentTokenJSON/PaymentTokenJSON.html.

http://apps.cybersource.com/library/documentation/dev_guides/apple_payments/SO_API/Apple_Pay_SO_API.pdf may be helpful too.

Very helpful, thank you.  As per the document you listed, does the Kill Bill cybersource plugin only support option 1 "Merchant Decryption"?  I believe I am coming from the option 2 "CyberSource Decryption" perspective, given my existing app (which we are phasing out) uses the Cybersource API that is related to option 2.  If the existing plugin doesn't support option 2, then I need to do the decryption myself.  Is this correct?

[Pierre-Alexandre Meyer]

On Mon, Dec 19, 2016 at 1:40 PM, Michael Cassano <mcas...@squaretrade.com> wrote:

As per the document you listed, does the Kill Bill cybersource plugin only support option 1 "Merchant Decryption"?  I believe I am coming from the option 2 "CyberSource Decryption" perspective, given my existing app (which we are phasing out) uses the Cybersource API that is related to option 2.  If the existing plugin doesn't support option 2, then I need to do the decryption myself.  Is this correct?

Indeed, only option 1 (merchant decryption) is supported today. I don't think it would be hard to add support for option 2 though. Looking at the documentation, we simply need to pass an <encryptedPayment> block instead of the individual fields (see here).

If you have some time to implement and test this flow, happy to accept a PR for it. Otherwise, you would need to switch to option 1.

--

Pierre