Troubles with Paypal Adaptive Payments API

Question

I'm having trouble with the Chained Payments API, still in development.

Speaking for the sandbox: I've read that, for some reason, the PayKey (the unique identifier Paypal creates for the transaction), is not passed back to the transaction. And certainly, in my testing, I get most the data back (like the buyer's email address, name, address information) but I do not get the paykey back.

This field is not just blank, it's not present at all. I'm doing the most basic loop over the form scope and writing the results to a file (obviously I won't be doing something this rudimentary in production, this was just to understand what data I was getting).

So I thought I'd pass my own unique identifier, store that in the database, and then pass that through the custom variable. This, (the custom field) oddly, comes back blank every time.

Finally I thought I'd just pass it as part of the url of the IpnNotificationUrl like receipt.cfm?myKey=SOMEVERYRANDOMLYGENERATEDKEYHERE but when I pass IpnNotificationUrl, the specified url is not pinged, whether or not I have a separate IPN Notification URL setup in my sandbox account. The URL specified in the account is properly pinged each time.

Both files are identical except that they write to differently named text files. I'm not getting an error off either file.

<cfoutput><cfsavecontent variable="buildfile">--- Break ---
    <cfloop list="#structkeylist(form)#" index="i">
    #i#: #form[i]#
    </cfloop>
</cfsavecontent></cfoutput>

<cffile file="#expandpath(".")#\dump_new.txt" action="write" output="#buildfile#" />

I need to be able to create a key and pass through Paypal or Paypal needs to pass back.

For what it's worth, this is my invocation from Paypal's SDK on GitHub

    <cfinvoke component="svc.adaptivepayments" method="payRequest" returnvariable="response">
        <cfinvokeargument name="returnURL" value="#request.serverURL#/success.cfm">
        <cfinvokeargument name="cancelURL" value="#request.serverURL#/cancel.cfm">
        <cfinvokeargument name="ipnNotificationUrl" value="http://myurl/taction/pp_rect2.cfm">
        <cfinvokeargument name="senderEmail" value="">
        <cfinvokeargument name="custom" value="test data">
        <cfinvokeargument name="receiverAmount" value="#ArrayToList(pp_amounts)#">
        <cfinvokeargument name="receiverEmail" value="#ArrayToList(pp_emails)#">
        <cfinvokeargument name="receiverPrimary" value="true,false,false,false,false,false">
        <cfinvokeargument name="feesPayer" value="PRIMARYRECEIVER">
        <cfinvokeargument name="receiverPaymentType" value="DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS,DIGITALGOODS">
        <cfinvokeargument name="actionType" value="PAY">
        <cfinvokeargument name="currencyCode" value="USD">
    </cfinvoke>

Edit: For clarification, Paykey comes back from this service, it's how I generate the link to send the user to paypal. Paykey simply doesn't get passed to my IPN, though other transaction data does. I removed certain information. And I've double checked, none of this information is the paykey or is available at time of paykey creation (so there's no unique identifier on both ends)

--- Break ---

    payer_email: redacted

    charset: windows-1252

    item_name: 

    payment_gross: 10.00

    payer_id: A62WKW8N3YDYU

    transaction_subject: 

    item_number: 

    payment_status: Completed

    payment_fee: 0.55

    notify_version: 3.8

    verify_sign: A.CSYz4u5IILQm5wM0J0JbJiIcEuAHODNEgw.2k7ZMYT31eXFO6G0R1o

    mc_currency: USD

    quantity: 0

    residence_country: US

    tax: 0.00

    first_name: John

    receiver_email: redacted

    last_name: Blow

    mc_fee: 0.55

    ipn_track_id: dd4151b653ead

    payer_status: verified

    custom: 

    fieldnames: payer_email,charset,item_name,payment_gross,payer_id,transaction_subject,
    item_number,payment_status,payment_fee,notify_version,verify_sign,
    mc_currency,quantity,residence_country,tax,first_name,receiver_email,
    last_name,mc_fee,ipn_track_id,payer_status,custom,mc_gross,test_ipn,
    business,txn_id,receiver_id,txn_type,payment_type,payment_date,protection_eligibility

    mc_gross: 10.00

    test_ipn: 1

    business: redacted

    txn_id: 71N09598H1922352W

    receiver_id: VBETUFDEQL5BC

    txn_type: web_accept

    payment_type: instant

    payment_date: 12:53:10 Nov 04, 2014 PST

    protection_eligibility: Ineligible

Answer 1

I think you're getting lost in the fact that Adaptive Payments transactions actually have separate IPN's for the app and for the receiver. In cases where you're acting as both, you would get 2 separate IPN's.

What you've included here is the receiver/transaction specific IPN. That would not include a PayKey, but instead, a transaction ID, like you're getting. You'll notice there is no PayKey parameter at all (as opposed to it being included, but blank, like you originally stated.)

If you want to process app specific data, including the PayKey, you'll need do that from within the app specific IPN, which is what I linked you to for my sample. You'll notice the parameters it includes are much different than what you're getting here.

In my sample, I was indeed both the app owner and the receiver of the transaction, so I got 2 IPN's at the same time, but of course my IPN script is configured to handle them accordingly.

So again, I had an app specific IPN, which includes app specific data including the PayKey. Then I also got a separate transaction specific IPN, which includes data like you're showing here, but does not include a PayKey.

You need to make sure you're handling both correctly. The IPNNotificationURL parameter in your Pay request would trigger the app specific IPN, where-as the IPN config in the receiver account would trigger the transaction specific IPN.

I see that you are including a value for IPNNotificationURL in your request, but the data you're getting is not that. You need to check your web server logs because it seems like that one must be failing for some reason, but then the other is hitting and succeeding.