After reading some source code I saw that neither checkout-server-sdk nor payouts-server-sdk contain libraries to implement easily subscriptions.
So what is the right way to proceed today?
Use deprecated paypal-rest-sdk? Implement REST api? Render Paypal Smart Button and use webhooks or anything else?
The Subscriptions documentation explains how to integrate it. Any API calls you implement require a direct HTTP integration, as there is no SDK for subscriptions.
Do not use a deprecated SDK -- apart from the fact that it is deprecated and should not be used for anything, it is also not compatible with the current version of PayPal Subscriptions.
Webhooks are necessary for notification of future events. Webhook event names for subscriptions are listed here, but essentially you can just listen for PAYMENT.SALE.COMPLETED and have all logic be driven based on initial receipt and noting when you expect the next one for the subscription to continue.
For reconciliation, the parameter custom_id can be set when a subscription is created; its value will be returned in future webhooks and other queries of the subscription's status.
Related
Note: I'm using the Node.js SDK, but I assume all Stripe SDKs are thin wrappers around their REST API.
How can I handle card authentication/3D-Secure/next steps when working with subscriptions and receiving a status == incomplete after creating a new subscription?
The documentation isn't very clear about it. It seems that Subscription objects are a higher-order abstraction over PaymentIntent objects, with recurring charges, free trial days, things like this.
However, it seems to be impossible to actually work with a PaymentIntent once you've created a subscription. And the only way to retrieve a PaymentIntent seems to be by using its associated pi_ ID.
Thanks in advance.
Have you seen the Build a subscription guide on Stripe's documentation? Specifically this section, where you collect payment details and confirm the Payment Intent returned on the Subscription object in your applications front-end.
I am working on integrating stripe subscriptions in a website. So, I am thinking about using the subscription.status to monitor payment. So, once the current period ends, I check the subscription. If active, great, I update the user data. If not, then I act accordingly based on the status.
However, it seems to be that webhooks are the correct way to do this. Why is that better than just checking the status? It seems pretty much the same to me.
Using webhooks will allow you to keep a track of a whole bunch of things rather than just the status of a subscription [1].
You can design a webhook endpoint to listen to various events such as;
Whenever a new subscription is created or an existing subscription is
canceled
In case you offer multiple plans for subscription, you will
be notified if a customer switches from one plan to another
Whenever an invoice is created, finalized, paid or in-case payment attempt fails
If you don't use webhooks, you will have to constantly poll for status changes until the status actually does change. That approach isn’t really scalable. So instead of having to keep looking for the information, with a webhook the information would come to you.
So instead of having to keep looking for the information, information itself would come to you. You can use the webhook events as triggers to handle any operations you’d want to perform on your backend.
It will also increase the scalability of your app as there are plenty of other events you can listen for [2].
[1] https://stripe.com/docs/webhooks#use-cases
[2] https://stripe.com/docs/api/webhook_endpoints/create#create_webhook_endpoint-enabled_events
I see paypal is upgrading their APIs. I want to collect recurring payments and provide a feature to upgrade / downgrade the plans.
In the samples, paypal is using billing agreements and when I see the docs, it says the API is deprecated please use subscriptions API. I am confused which one to use.
Please help me in this.
PS: Also my product includes one time payments
The PayPal Subscriptions API uses billing agreements and plans, and there are multiple versions. Everything linked from https://developer.paypal.com/docs/subscriptions/integrate/ will be the most recent version.
For one-time (non-subscription) payments, the most robust integration is to have two routes on your server that implement v2/checkout/orders API calls to "create order" and "capture order", combined with this front end: https://developer.paypal.com/demo/checkout/#/pattern/server
For a subscription integration to be similarly robust (in that your server gets an immediate API response of profile activation), you can have those buttons call your server as well: PayPal Smart Subscribe server side
Is there a way to send proactive cards from a bot to a Teams channel? The use case is a channel for service tickets. Once they get posted, a user will be able to interact with them with a few actions.
I’m looking at the documentation here for sending proactive messages. At the bottom, there’s a section for ”Creating channel conversations”, with a small reference to the startReplyChain(). However, the actual code and sample on GitHub still seem to reference a conversation with a member rather than sending something proactive to a channel.
There does appear to be documentation for incoming and outgoing webhooks, which is what I may end up doing. My only real concern is that it requires using Actionable Cards, which it references as legacy everywhere. This is despite saying that you can’t send Adaptive Cards with them. Perhaps they intend to enable these connectors to send Adaptive Cards, it’s not just very clear to me if this is a long-term solution I should be focusing on.
This is definitely possible, and it's important to note that you can even send from another process/application (e.g. on a schedule from an AWS Lamba). You can see a sample here for this.
The process of sending the message is just part of the story though - you need to have certain information already saved (e.g. in your database) to know how to contact the right user, group chat, or channel conversation, but there are a few ways to get that information. The most common is, when you bot is added to the conversation, to get it from the conversationUpdate event. You'll need conversation id, service url, tenant id, and your bot's App Id (what you get in the Azure portal for your bot, and which you're using already in your app's configuration, teams manifest, etc.). You can read more about the topic here and here.
Another option, if you don't have access to conversationUpdate (e.g. the user hasn't installed your app) is to call the Graph API to install your app. It's only possible to do this to a channel (on the v1 or beta api) (see here) or to a user (see here), but on the beta api only, and not (yet?) for a group chat.
We are doing an integration with DocuSign where users can submit documents stored in our system to DocuSign to get the documents signed. We have the DocuSign Connect feature working in our demo account. We can process messages from DocuSign successfully.
We were concerned that getting users to add a Connect Configuration themselves may be too challenging for some and it will be error-prone.
I see now in the documentation that it is possible to automatically get DocuSign to push notifications by passing the information in the EventNotification attribute when we call createEnvelope. Is this an acceptable way to get push notifications from DocuSign? Will this cause issues with getting the integration certified?
Is there any other way to get Connect configured easily in customer accounts?
This is an old question, but I wanted, for the record to have answers, since it's important to anyone who may be reading this.
We see now in the documentation that it is possible to automatically
get DocuSign to push notifications by passing the information in the
EventNotification attribute when we call createEnvelope. Is this an
acceptable way to get push notifications from DocuSign?
Yes, it is. It's a very good way in fact, to reduce polling and make your app better. We highly recommend that you use EvenNotification and sign-up for events going through a webhook to your app such that you can handle them in your code only when they occur, instead of polling DocuSign APIs repeatedly.
Will this cause issues with getting the integration certified?
The opposite is true. If you use polling you may have issues being certified. Using connect events with a webhook is one way to avoid the need for excessive polling which could cause issues with the certification.
Is there any other way to get Connect configured easily in customer
accounts?
You can configure connect like you suggested using EventNotification at the envelope level. This approach works well for ISVs since you don't need your customers to have admin access to their accounts.
The other option is account-level connect configuration, which does require admin level access and there are some other limitations. This approach adds the connect webhook for all envelopes in the account. So it may or may not be better, depending on your scenario.