I have an endpoint responsible for creating a paid subscription. However, in order to create subscription I need to access multiple different services in succession:
1) create subscription with a token provided by front-end (generated by a direct call from front-end app to payment system) (Call to the payment system)
2) get Billing information to save in database (Call to the payment system)
3) save some of billing info (f_name, l_name) and provided shipping info (Call to the database)
4) subscribe customer to the mailing list (Call to the email service provider)
Any of these steps can fail due to service being unavailable, problems with internet connection in the DC or any other number of problems that are not controllable by developers. Is there any options to process all of this in a transaction-like manner to avoid partial completion? e.g. We create subscription, but don't write to database.
I am using Node.js, if this helps.
Have a look at the Saga pattern for microservices. This could essentially be laid out as a service which you contact when you want to create a subscription. It knows every step involved and on top of that, also knows how to roll back every transaction, should any step fail.
Upon making a request, the service would just start doing all the necessary requests/queries and then either:
Return successfully
Rollback all transactions that have happened so far and return an error
This obviously relies on all of your services being able to revert to known good state.
Another approach would be to use two-phase/n-phase commits, but they may impose a big performance drop which is not desirable for something user-facing.
You may want to read through this discussion on HackerNews where this problem is discussed in far more detail.
Related
I am collecting a payment using Stripe, and want to keep a portion, and send the rest onto another account from another organisation.
Stripe have told me that I have to connect an account. I have done this, Stripe gives me a link which the other organisation pastes into their browser, and all works. I can create a transfer linked to a payment intent.
But, when the link is pasted into the other organistions browser, this message is shown.
______ will be able to see your account data (such as all payment and payout history), including any data created by other business you've connected. They'll also be able to create new payments and take other actions for you.
This seems crazy - I just want to pay them some money, not ask them for full access.
Am I missing a trick?
Stripe Connect is a product/tool that allows accounts to work together to provide goods and services to end customers. There are a few different approaches to how this is configured based on your use case as well as whether you would be acting as the Platform (the one in control) or the Connect Account.
You should review the different Connect Account Types and determine what best matches your use case. Some questions to consider are as follows:
Who is interfacing with the end-customer (you or the other account)?
Who is providing the product/service?
Is this other account providing a service to you in exchange for a cut of the revenue?
On what account should the transactions and customers be stored?
It sounds like, based on the warning message, you were creating the other account to be the Platform and you would be Connect Account. In that cases the other account could make API calls on your behalf using your account token. This would be normal if the other account is providing a service to you like funneling customers to you in some way. A good way to quickly review what approach makes the most sense for your use case is to review the Funds Flow diagrams for the different types of Charges
Direct Charges
Destination Charges
Separate Charges and Transfers
Testing out the platform I was running on both a developer account and a Trial Business Pro account until I purchased a standard plan.
Up until I purchased the standard plan, envelope statuses would update by the second and the functionality built with the Apex Toolkit was working well.
Once changing to the standard paid plan, envelopes statuses take 10-15 minutes to update and some functionality is not working.
My question is:
Do the different plans have different status updating times in Salesforce?
Is functionality of the Apex Toolkit limited between the different plans?
Does the Connect option (which is missing now) have anything to do with the above?
Thanks!
They do not. Writeback to Salesforce takes place via DocuSign Connect. Some plans don't support Connect out of the box but the actual writeback times / delays do not differ between account plan types.
Indirectly, the only way that a plan type can interfere with an API call that worked on another plan type is if it had entitlement to a feature that your new plan does not, IE: The ability to allow Comments, to set recipient signing language, to set envelopeID Stamp Control, etc...
I would highly suspect that it does -- in fact I'm a little surprised that your writebacks are happening at all if you don't have Connect enabled. Salesforce adds an object reference IE: Opportunity / AccountIds to the envelope's custom fields on send. When Connect sees these fields, it knows to write back to that specific object. Without Connect enabled and configured it shouldn't be able to process these writebacks at all.
I think you should have a conversation with your Account Rep first regarding Connect entitlement, then you can reconnect your Salesforce instances to the updated DocuSign account which is something that we can help you with.
Regards,
Matt
I am after the best practice for handling incomplete stripe connected account onboarding.
When onboarding goes smoothly, everything is simple. But there are fiddly edgecases everywhere, which results in a lot of permutations of values for account requirements
These include
current_deadline
currently_due
disabled_reason
errors
eventually_due
past_due
pending_verification
This creates a lot of complexity.
I need a simple way to:
figure out if the connected user needs to be notified of something (i.e. that they need to give more info), and
what to tell them.
My current strategy is to check if errors is empty, and if not, simply display them along with a link to manage the user's stripe account so they can address the errors.
But I'm worried this strategy will miss things (perhaps minor things that could be addressed before they become errors).
TL;DR I suspect most users will onboard without any problem, but for the few who do have issues, I want to ensure the app notifies them that they need to address them. What is the best way to do this? (using the information in requirements or other info)
When handling identity verification manually using the API, a simple way to check whether your connected user might need to be notified to provide more info is to look at the charges_enabled and payouts_enabled properties on the user's account object. If either of these two properties are false then you might need to reach out to the connected user for more information.
In cases where the connected user's charges and payouts are disabled, you would use the disabled_reason property on the requirements hash to learn the reason why charges and/or payouts are disabled. The possible disabled reasons are all documented here, but I'll list them out nonetheless:
action_required.requested_capabilities You need to request
capabilities for the connected account. For details, see Request and
unrequest capabilities.
requirements.past_due Additional verification
information is required to enable payout or charge capabilities on
this account.
requirements.pending_verification Stripe is currently
verifying information on the connected account.
rejected.fraud Account is rejected due to suspected fraud or illegal activity.
rejected.terms_of_service Account is rejected due to suspected terms
of service violations.
rejected.listed Account is rejected because
it's on a third-party prohibited persons or companies list (such as
financial services provider or government).
rejected.other Account is rejected for another reason.
listed Account might be on a prohibited persons or companies list (Stripe will investigate and either reject or reinstate the account appropriately).
under_review Account is under review by Stripe.
other Account isn't rejected but is disabled for another reason while being reviewed.
Using the disabled_reason, you can assess whether the user needs to be notified with a request for more information (i.e., requirements.past_due), whether they need to be notified for another reason (e.g., rejected.listed), or whether you need to make programmatic changes to the user's Stripe account (e.g., action_required.requested_capabilities).
Im trying to decouple these 2, account and user service.
On user register, the user enters in their account information (business name, tax number etc) + user information (profile settings etc).
Im wondering what is the best approach to decouple these two services on signup to get the one form submission to be stored in these 2 services?
Currently i have a setup, where when a user registers, it sends a post request to the auth service where, the auth service fires a webhook to account and user service.
I feel like this is prone to errors and might not be the standard approach.
I’d like to know how to properly do this - i.e how does netflix, google etc do this
Many thanks!
You need a mechanism for implementing transactions that spans multiple microservices. In this case, the microservice architecture suggests using the SAGA design pattern with compensating transactions.
SAGA is actually a sequence of transactions for a set of microservices. Each transaction updates each microservice, which updates its own database and publishes a message or event to start the next transaction in the saga to update the next microservice. If such a transaction fails in any microservice, then SAGA performs a series of compensating transactions that undo the changes made by previous transactions.
SAGA are divided into 2 types:
Choreography - each transaction publishes events that trigger transactions in other microservices in turn (without an orchestrator).
Orchestration - there is a separate orchestrator that manages transactions and tells the participants what transactions need to be performed.
You should also keep in mind that when you add such a pattern to the architecture, the complexity of the architecture increases significantly, for more information about the problems and disadvantages, see the link.
More details can be found at links 1 and 2.
Likely yes, the approach is correct, the service among the two which gets data directly from frontend has the responsibility of sending an asynchronous event to the other service so that it can also mutate the data in it's database and data consistency remains maintained, i.e. paradigm of eventual consistency itself.
Only the thing is that the message carriers/ brokers should be highly available.
For my Azure app I have a variety of scenarios for needing both scheduled and triggers jobs. Having researched both Azure WebJobs and Scheduler it appears I can accomplish this, but not in the best way possible.
My use cases will go something like:
Weekly email blast (seems right up the alley for Scheduler)
Event invites, dynamically timed based on event's time (I could have
a job check every hour to see if any need to be sent? or at the
event's creation create a Scheduled Job at the specific time, but
what happens if the event changes?)
Reminders based on #2 above
(same issues/questions)
Welcome emails (two versions, one if they
complete a walkthrough and another if they don't: how to manage the
timing of this?)
So basically I see how I can use Azure Scheduler to accomplish all of this, but not in the most efficient way. I would like to see if there's a way to manage Azure Scheduler along with some sort of triggered Jobs based on various criteria, controller by code. Does something like this exist?
Update
To add a bit more information to this,
I'm using Mandrill as these are transactional emails. The things that makes my use case not appropriate for Mailchimp or some automation platform is I have repeat templates I will be sending out (5ish) which are triggered dynamically based on my user's events and various configurations.
Examples:
1) New user registers. If they complete an on-boarding walkthrough they receive one type of welcome email, if they don't complete the on-boarding walkthrough within x minutes they receive an other type of welcome email.
2) An event is created by an admin. At that moment code will comb through all users to see who should be invited based on user's preferences, then send out personalized invites to each user.
Consider using the WebJobs SDK for some of this. For example, you could use an Azure Storage Queue to invoke your web job as event invites are created or modified in your application. You may want to have different queues that different web jobs are triggered from too. For example, one for invites, another for reminders, and one for welcome emails.
The weekly email blast may be a separate scheduled web job in your scenario.
Putting my business cap on, it sounds like you have a need of something that will handle your email marketing/automation. Consider looking at 3rd party products that specialize in this, instead of hand-coding it. Mailchimp # http://mailchimp.com comes to mind. They have a feature called Goal completion more info at: http://blog.mailchimp.com/new-trigger-emails-from-website-traffic/
Alternatively, a monitoring and automation service that my company provides (CloudMonix # http://cloudmonix.com ) allows for automatically kicking off tasks based on some very custom criteria. CloudMonix knows nothing about email marketing, but it can kick-off a Web job or an Azure automation job if some SQL record appeared in the database or a metric published somewhere.