I recently increased the prices of my Stripe subscription plans on my Laravel SASS application. Now, when a user cancels their subscription, it throws the following error:
"The subscription is managed by the subscription schedule sub_sched_XXXXXXXXXX, and updating any cancelation behavior directly is not allowed. Please update the schedule instead."
I'm using Laravel 5.6 and have this in my composer.json file:
"laravel/cashier": "~7.0",
Basically, I get the subscription object and just call cancel(). E.g.:
$subscription->cancel();
This worked for years until I recently changed my prices. Is this a programming error on my part, or do I need to move my subscription plans off of schedules somehow? I'm really stumped here, because Googling has not turned up any useful results on this error.
Found the issue. The recent price change moved the subscriptions onto a schedule. I had to release the subscription schedule using the API here:
https://stripe.com/docs/api/subscription_schedules/release?lang=php
Related
On this documentation, it said that both can be used, but what's the difference between the two? Their code seems to be identical as well.
I found the answer, it seems that WebhookReceived is triggered BEFORE Laravel Cashier do any logic with the webhook event, while WebhookHandled is triggered AFTER Laravel Cashier did their logic.
So if you received a customer.subscription.created event.
WebhookReceived will trigger before there are any data on the database with that event while WebhookHandled will trigger with the new subscription available in the database.
I cannot find the answer to this question that I once found. Basically I was able to create a stripe subscription using Laravel Cashier, and then trigger via code the subscription to be billed again, so I could test my invoice succeeded webhook. I am using Laravel Cashier. I recall I used ngrok to proxy, so I could get my webhook to work.
Basically it is recharging an active subscription. Any help would be great. PHP preferably.
The best option for now is to create a Subscription with a short trial period of a few minutes using the trial_end parameter. This lets you create a Subscription that will renew a few minutes later to simulate a new period that is starting.
There is no way to "fast forward time" or similar to go through multiple cycles in a few minutes otherwise.
As for webhooks the best option is to use Stripe's CLI: https://stripe.com/docs/stripe-cli
i am using cashier 10 and stripe 7 and i am creating monthly, yearly and life time subscription.
Montlhy and Yealry subscription is working fine but life time charge generate error
The provided PaymentMethod is already attached to another object. You cannot reuse PaymentMethods without attaching them to a Customer object first.
in controller
$user->charge((int)$request->plan_price*100, $request->paymentMethod);
I have written multiple audit reports for my saas apps over the last few years. Most of the logic uses the PayPal API to get the full transaction list (using TransactionSearch) and then for each transaction, get the details (using GetTransactionDetails).
The intent is to line up my database records of recurring payments received with the latest PayPal data to make sure I didn't miss an IPN or anything.
This worked fine up until about a month ago.
Lately, the subscription ID is missing from most transactions.
In the past, subscription ID was contained in the "SUBSCRIPTIONID" NVP field. This is no longer there for all transactions, and I don't see any other fields returned that contain a subscription ID. All other fields seem to be there though, so I know my calls are working. It's just the NVP response is missing the subscription ID. I have also verified that the subscription ID is included with the IPN sent for the same transactions.
My code is using an older API version (108.0). Now in theory, PayPal won't ever change how an API works, so I'm baffled as to why results are no longer what they were with the same codebase a month ago.
I tried the latest API version (124.0), and it provides subscription ID's for more transactions than 108, but also not all of them.
I'm totally stumped here. Does anyone have any clues?
I don't want to ask PayPal support, because it will take 3 weeks to get no help at all :-)
Had the same issue for a month as well just stopped working randomly was going to try the latest version but if your say its the same then think the best course of action is file a bug report with paypal.
The only valid work around I found is to save the created api call which will return the email and subscription id.
Then use the information from get transaction id (email) to search the subscription id from the original database (created). Messy but works for now until they fix this issue.
FOLLOW UP
I am using this method to just keep making the api call until the subscription id is made as we know it does work every 1 in 5 tries.
try {
/* Original call */
$transDetailsResponse = $paypalService->GetTransactionDetails($request);
} catch (Exception $ex) {
include_once("../Error.php");
exit;
}
// If its not got sub id we start a while loop
if ($transDetailsResponse->PaymentTransactionDetails->PaymentItemInfo->Subscription->SubscriptionID == "")
{
// Run while loop until its found
while ($transDetailsResponse->PaymentTransactionDetails->PaymentItemInfo->Subscription->SubscriptionID=="")
{
try {
$transDetailsResponse = $paypalService->GetTransactionDetails($request);
} catch (Exception $ex) {
include_once("../Error.php");
exit;
}
}
I'm afraid I don't have an answer but I can't see any way for me to participate in this discussion, since I don't have enough reputation to make comments.
I have been having this same problem for a couple of weeks now. (In fact, I can tell that the problems first started with a change on 2016-03-07). https://stackoverflow.com/questions/36647177/paypal-api-has-stopped-sending-profile-ids-any-way-to-match-payments-up-to-a-s
I have noticed today that we have started receiving SUBSCRIPTIONIDs again. However the TRANSACTIONTYPE has changed to 'recurring_payment' instead of 'subscrpayment'.
Have also found that we are receiving transaction details from other sellers entirely mashed up with our transaction details -- product NAME lines that are absolutely nothing at all to do with our business. Completely broken and potentially a security problem.
I've opened several tickets with paypal-techsupport.com to describe these issues but I have not heard back from them yet.
PayPal support has finally responded with this:
The products teams are reporting that this issue should be resolved.
Please let us know if you are still seeing instances of this issue.
With the release of the new subscription option from In-App Billing API we started a proof of concept of the service and we found a few issues. Has anyone else tried it and would have some answers for us? Here's the issues we have been facing so far:
1 – While testing the unsubscribe functionality, the Google Play interface displays a white page with an “Item not found” message and a retry button. Is it due to the fact the app is not yet published? If yes, how can we test this flow without publishing it first?
2 – Inter device synchronization. When making a subscription on one device, other devices tied to the same account did not receive a OnPurchaseStateChange event. Is it again due to the fact the app is not published? Or are subscriptions tied to a particular device and not to an account?
3 – On our Google merchant page, when we cancel a purchase, the device does not receive a notification telling the subscription has been cancelled. Is this a bug? As a workaround we are manually checking the current time and comparing with the expiration date to force a restore transactions call. At this point, we are able to see the subscription is no longer valid. Do you think this is an acceptable solution?
4 – When a subscription is made, two transactions show up on the Google Merchant page: a FAILED transaction with a value of $0 and a valid one with the value we charged. Is this the expected behavior? What’s the purpose of the $0 FAILED transaction?
If anyone has faced similar issues we would like to know. Maybe these could be bugs on Google's end or maybe we did not understand 100% how it is supposed to work.
Thanks in advance.
1.I had the same issue and after I published (and later unpublished) my app I could see the app page in the market,so you can publish and than unpublish.
2.I didn't check it with subscriptions ,but for managed item i didn't get purchaseStateChange on two different devices as expected.
3.I do get subscription expired after canceling one,but only after a while.
I didn't understood how you can get the expiration date ?
you only can get it with access to play developer api.
the restore transactions will give you same purchaseStateChange as you got when purchase the item.
*in the developer guide it is recommanded to use restore transactions only in first app use.
4.I have same issue,and i heard at least about 10 people with same 0$ charge.