I'm developing an application that uses Stripe, through Laravel Cashier to handle user subscriptions. When the user account is made, It has to be manually verified (has to be done this way due to the business logic) however the subscription starts immediately. Is there a way to pause the subscription, and only start it once each account has been verified? I'm using Laravel 5.
I think something like the following could work:
Create a boolean variable in your "users" table that you could call something like "verify_subscription".
Whenever a new user account is created, set "verify_subscription" to false.
Don't send the subscription off to Stripe (which will pause the subscription) while a new user has their "verify_subscription" set to false.
I can think of two different options at this point: Either create a confirmation email that gets sent to you (instead of or in addition to the user) where when you are ready to unpause the subscription you can click on that link for that particular user which will send the subscription off to Stripe and "unpause" their subscription OR you could create a route with a form where you can look up the user who you would like to unpause and simply search for that user, submit a form that gets processed which does the same thing (unpause the user by sending the subscription off to Stripe).
Hope that gives you some ideas to work with if you haven't already solved this issue!
Related
I am new to AWS, and facing a problem with Amazon Connect and Lex.
I have 11 intents in my Lex bot. In Amazon Connect Contact Flow inside the "Get Customer Input" I have included only 5 out of 11 intents. Get Customer Input screenshot.
My problem is that I want to restrict Lex to those certain intents, i.e. when a user speaks, "Get Customer Input" should trigger only one of those 5 intents instead of triggering one of all 11 intents that are in the bot.
Intents that I have inside Get Customer Input:
newRes: when a customer says New Reservation
removePreviousRes: when a customer says Delete my Reservation or Cancel my Reservation
updatePreviousRes: when a customer says Change my Reservation or Update my Reservation
checkRideStatus: when a user says What is the status of my ride
getAnOperator: when a user says Talk to operator
I also have a newUser intent in the Lex bot which can be triggered by saying New User or New Account or something similar. Now if a user says New User or New Account at Get Customer Input block, newUser intent will be triggered even though I have not added it inside Get Customer Input block as a parameter. Is there a way to restrict Lex to only those 5 intents? Because I need the newUser intent later in the Contact Flow, and I don't want the user to trigger it at the start of Contact Flow. Any ideas? Can I restrict it using Lambda function?
You can definitely control this yourself using sessionAttributes and your Lambda Function.
You cannot stop Lex from attempting to match user input to some of your intents, however, you can check if those intents are triggered when you don't want them to be, based on a variable that you can create to keep track of where the user is in the conversation across multiple intents.
To do that, make use of Lex's sessionAttributes. These can also be created or updated inside of Connect. You can also receive Lex's sessionAttributes in Connect as an "External" Contact Attribute: $.Lex.SessionAttributes.attributeKey
For example:
Set up an attribute called convo_point and set the value at start of the Connect conversation as "initiate" or "beginning". Then consider your conversation flow and the different check points you need where you can allow or disallow certain intents.
Then inside of your Lex's Lambda, before handling each intent, check this convo_point sessionAttribute and compare with the triggered intent. If the convo point is too early for New User intent, then build a proper response with an ElicitIntent response type and ask the user to try a different intent. As the user fulfills other intents, then you can update the convo_point to reflect that and allow the New User intent to be fulfilled only after that has happened.
I'm developing an invoicing system in order to collect payments from customers. Once I create an invoice, an email including invoice details will be sent to the customers with payment link. I want to re-generate payment token(once it expires) and send renewed payment link to the customers, and want to automate the process.
I created a Job called renewingInvoiceLinks and inside the handle method, I wrote code to retrieve all invoices with expired links and create new token and send new link. In App->Console->Kernel.php scheduled the job as following. I referred Laravel Docs but did not get the flow properly to dispatch the Job.
protected function schedule(Schedule $schedule)
{
$schedule->job(new renewingInvoiceLinks, 'renewingInvoiceLinks')->daily();
}
Things I want to get clear.
Whether using Job to do the requirement is correct or not? If not what is the perfect way to do it.
How to dispatch the Job? (Where I need to call the dispatch method?)
I think the question is quite subjective and opinionated, but here is how I'd do it:
Whenever the payment link is updated, I would fire a custom PaymentLinkUpdated event. You can either fire this event in the place(s) where you update the link, or you listen for the saving event on the affected model and fire the PaymentLinkUpdated event only when the original value is different from the updated one.
A custom event listener will listen for the update of payment links and will send out the email containing the payment details and link. This event listener should be a queued one so that emails are sent in the background and do not block the UI.
A scheduled job will check for expired payment links and will update the affected records, casting a PaymentLinkUpdated event where necessary. This will trigger step 2 (which is automatically queued again).
This way, you'd have all the logic implemented only once and sending mails would not be duplicated. If you have to send a different mail when the payment link is renewed, you can either do so in the event listener or you have to change your strategy entirely.
I am developing a Laravel application that involves subscription payment. Now I am struggling with subscribing the user with token but using the existing customer. This is the scenario. In my application, user can update their payment/ billing information (basically card). When they update the payment info, they are just adding the card information. Then later, user can make payment or subscribe to whatever they want.
First user will add they payment method or card information. So I create the customer like this.
$user->createAsStripeCustomer($token, array_merge($options, [
'email' => 'email address',
]));
So the above method will create the stripe customer for the user along with the card. Then tomorrow, user might want to subscribe to a channel. Laravel Cashier provide the following method to subscribe.
$user->newSubscription('subscription-name', 'my-plan')->create($token);
Then issue with the above code is that, I have to pass the token again. If I have to pass the token, again, I will have to generate the token again in the Javascript. If I have to generate the token again in the javascript, I will have to ask the user to enter the card information again to get token. So what can I do to get user to subscribe using the existing customer info? How can I do that?
One method is whenever you create a stripe customer, add the user to a free subscription plan so that he doesn't have to pay anything until he subscribes. When the user starts subscription we can simply change the subscription plan to the desired plan using the following method:
$user->subscription('main')
->skipTrial()
->swap('provider-plan-id');
Another method is whenever we create a stripe customer, ask the user to select a subscription plan and put him on the trial period until he subscribes.
I want to create something in Slack that sends a message (starting by calling someone with '#') to a channel when specific users login. I've checked ifttt and zapier. I also checked the slack api to create something myself, but I couldn't really find anything usefull.
Anyone has any ideas?
Slack does not track user login or logoff in a traditional sense. Instead, users are always always "logged in" and available to receive messages once they have joined a team / channel.
There also is the concept of "presence", which is related, but not the same thing. User presence can change multiple times during a few minutes, e.g. if the user is on a mobile. I am guessing you would not want to send the user your message that often.
Still you can poll the presence information of a user with the API users.getPresence , which could be used to implement a script that polls this information on a regular basis and send your message. You also want to filter out presence changes below a certain duration threshold.
Keep in mind though that the rate limit for API methods is 1 per second. So depending on how many users you have in your workspace there will be a significant delay between the user becoming "present" and your script being able to send the message.
There is a workaround for that to have a google sheet as a database for the users and you can trigger by day once and timestamp it.
So the best trigger is a private message or public and you can use filter when mentioning or signin or signout it depends on the trigger word then you pass the filter since zapier won't count your zaps if you used fiter as a second step.
We are using Google Checkout - google handled subscriptions. In our html form we are using merchant-item-id parameter to store the subscription plan id and user id, so when Google Checkout send us back the notification for the new orders (merchant-item-id is there) we know what user for what plan to charge. So far this works perfect.
But now, when a month is passed, and Google Checkout start creating the reoccurring orders, there is no merchant-item-id parameter in the notifications they send. So we don't know what user for what plan is charged.
What should we use as user identifier, so we can handle properly the subscription on our site?
Any ideas?
Btw. I know about the "buyer-id" parameter which is send with each new order notification, but that will not work for us, because it is possible that the same google buyer is paying for several of our users accounts.
I would try putting some unique info in "shopping-cart.items.item-1.merchant-private-item-data" to something unique that I can identify the subscription by.
Nikolaj