Home → Questions →

PayPal integration - reference transactions deprecated

• Edit

Jan Kondratowicz

29 May, 2017 02:22 PM

Hi,

We're trying to set up payments using PayPal API in our application. CheddarGetter guide says we need to get "approved for Reference Transactions by PayPal" and directly points to this page:
https://developer.paypal.com/docs/classic/express-checkout/integrat...

But PayPal documentation states that Reference Transactions are part of deprecated SOAP API, so I can't even use this feature. Docs for REST API mention Future Transactions, which seem to be the same thing, plus I see it's reachable using PayPal-node-SDK we're using. But the question is - is that the same thing? Could you please update your documentation?

1. 1 Posted by Jan Kondratowic... on 30 May, 2017 09:03 AM

   

   A follow-up question, because the docs aren't clear on that or I'm just slow. I have a single pricing plan with 7 day trial (first invoice scheduled 7 days after signup). In my application, I want to verify user's subscription status, so I call API to get single customer's data.

   Having the information returned by API, how do I check if user's subscription is active (either paid for or in trial)? I know it's not customer.subscription.plans[0].isActive, because this field is always 1, no matter if the subscription is paid or not. Also, trialDays is always 0, which is confusing. So I assume I have to look at some of the dates, but which ones? After trial expires, nextInvoiceBillingDatetime just shows the next invoice due in a month, despite the previous one not being paid yet...

   • Edit

2. Support Staff 2 Posted by Meghan Turner on 30 May, 2017 05:46 PM

   

   Hi Jan,

   On your first question, it's our understanding that PayPal is going to continue supporting the SOAP API for the foreseeable future because they don't yet have a comparable solution with the REST API that supports recurring payments. However, it seems that PayPal has been in the midst of making some updates to their system that they haven't been communicating to vendors particularly well, so we'll take another look at their documentation to make sure that's the case. If you have it, would you mind sending us the link to the documentation you saw about future transactions?

   On your question about checking customer status, there's no standardized way to check status because we like to leave it up to our customers to decide how active and inactive customers are defined in their application, but to provide a suggestion, we've had other customers use the canceledDatetime parameter in the customers/get response for this. In CG, customers who don't pay their bill a certain number of days after it becomes due (you define in your dunning settings how long this period of time is) are automatically canceled. If a customer's subscription is active and paid, the canceledDatetime parameter will be empty. If the customer has been canceled, the canceledDatetime parameter will have a date associated with it.

   Hope that helps, but let me know if you have any other questions! If you could get back to me with that future payments link, we'll do some more research on the PayPal REST API situation.

   Meghan

   • Edit

3. 3 Posted by Jan Kondratowic... on 31 May, 2017 08:02 AM

   

   Hi Meghan,

   Thanks for your answer. I've read up more on PayPal's REST API, my previous comment was wrong - future transations is a different feature, meant specifically for mobile payments:
   https://developer.paypal.com/docs/integration/mobile/make-future-pa...
   There are code samples in their mobile SDKs.

   As far as reference transactions go, closest I could find in their REST API is Billing Agreements API, but it seems to work a bit differently than what was used in SOAP API:
   https://developer.paypal.com/docs/api/payments.billing-agreements

   Anyway, I'll try to make it work using NVM/SOAP.

   As for the second issue, I'm still not sure how to achieve what we're looking for. Our new customers are not required to provide payment information, that's our idea of free trial - no obligations. I changed dunning suttings (max retries and interval) to 0, so am I correct in assuming that exactly 7 days after customer is created, canceledDatetime for this user will change from null to a date of expiration? And let's say a user pays (via PayPal) 14 days after initial registration (so 1 week after free trial expired) - I assume canceledDatetime will return to null ten, but how will I be able to calculate when is user's next payment due (should be 1 month + 14 days after initial registration)? Is it the nextInvoiceBillingDatetime field?

   Sorry for such specific questions, but that's just not clear to me from the docs without seeing examples, and it's difficult to test those things on my own because those scenarios rely on days/weeks passing.

   Best regards,

   Jan

   • Edit

4. Support Staff 4 Posted by Meghan Turner on 31 May, 2017 05:17 PM

   

   Hi Jan,

   Thanks for providing those links. Even though they're not exactly the same, we'll still take a look at REST API Billing agreement documentation. Let us know if you have any questions about the NVP/SOAP API as you're integrating it with your application.

   I changed dunning settings (max retries and interval) to 0, so am I correct in assuming that exactly 7 days after customer is created, canceledDatetime for this user will change from null to a date of expiration?

   Yes, that's correct, but I also want to point out that if Cheddar attempts to run a transaction for a customer who doesn't have a payment method saved yet (no credit card or PayPal account associated with their Cheddar customer record), they'll be canceled immediately regardless of the dunning settings. This means you could have a dunning schedule enabled that lets you re-try any declined transactions (which helps with churn) and Cheddar would still behave the way you want in the free trial scenario by canceling any customers who haven't added a payment method by the time their free trial expires.

   and let's say a user pays (via PayPal) 14 days after initial registration (so 1 week after free trial expired) - I assume canceledDatetime will return to null ten, but how will I be able to calculate when is user's next payment due (should be 1 month + 14 days after initial registration)? Is it the nextInvoiceBillingDatetime field?

   Correct, after a customer has reactivated their subscription the canceledDatetime will return to null. When reactivation occurs, Cheddar immediately transacts any outstanding invoices and calculates the customer's next bill date for you. To check when the customer's next bill date will be in the customers/get response, use the billingDatetime parameter associated with the pending invoice. The nextInvoiceBillingDatetime parameter has to do with the pricing plan, not the customer's next bill date.

   Calculating the next invoice date after reactivation can be a bit tricky because the next invoice date depends on how long the subscription was canceled, so relying on Cheddar to do that calculation for you should simplify things, but if you'd like to learn more about how Cheddar behaves in different reactivation scenarios, check out this knowledge base article to see an example of short cancel behavior with free trials, how you can override that behavior, an example of a long cancel with a free trial behavior and how to override that behavior.

   Sorry for such specific questions, but that's just not clear to me from the docs without seeing examples, and it's difficult to test those things on my own because those scenarios rely on days/weeks passing.

   I love specific questions :) Let me know if there's anything else you need or if you have any suggestions about how we could improve the docs/knowledge base to make things easier to understand!

   Meghan

   • Edit

5. 5 Posted by Jan Kondratowic... on 01 Jun, 2017 01:25 PM

   

   Thank you, I think I have no further questions, at least for now :)

   Have a nice day.

   Jan

   • Edit

6. Meghan Turner closed this discussion on 27 Jun, 2017 03:05 PM.