Using paddle on live mode

Hello,

There was a similar question a while back here: Problem with Paddle.

The user managed to solve this by:

Contacting Paddle support they say my domain is verified but checkouts is not enabled. So Paddle team enable checkout and verified my account. And the problem fixed

Let me know how it goes!

Best,

Bobby

They did not allow my Micro SaaS because it is automated social media.

So, I am giving up Paddle.

Someone here knows how to implement the subscription with Wave + Stripe?

Did Tony create any video about it?

It is possible? It is easy to bypass Paddle using Wave?

Ah that is very unfortunate...

Currently, only Paddle is available out of the box.

But what you could do is use the code from the following PR that implements Stripe instead of Paddle:

https://github.com/thedevdojo/wave/pull/38

It has not been fully tested yet, but the implementation looks good. We will probably review this soon and merge it so that it could be available out of the box with Wave.

Let me know how it goes!

Can it happen? Wave makes it easy to get around Paddle? https://github.com/thedevdojo/wave/pull/38/octordle

Thank you very much, Bobby. I chose to use Stripe instead of Paddle.

Hello all. I am in the same shoes as cassiolacerda, however my account got disabled even during SANDBOX tests for unknown reason. Had to contact the Paddle support and they told me they thought our app will be offering services and since it is not allowed in their rules, the account got temporarily suspended.

So having enough pain already I decided to search for WAVE + STRIPE and found the pull commit of magarrent too.

The initial testing caused me some troubles but they were not a result of the code, but my initial setup with Stripe. Bear in mind that if you login as a user, visit subscriptions in the profile and you see Error 500, then you did not set a test user inside of Stripe.

I've discovered a small issue where if the Username is disabled in the settings, the form shows correctly inside of welcome.blade.php and it passes the needed information, however the complete controller is still trying to save the username.

I believe the issue is that we have a check inside of the controller to a0pply the correct validation for settings WITH or WITHOUT username, however later we are trying to resolve what is the username from $request->username.

This should be easy to fix by adding an extra check for the auth.username_in_registration and if set to NO, to define some standard value for username that would be save to the DB.

Hello all. I am in the same shoes as cassiolacerda, however my account got disabled even during SANDBOX tests for unknown reason. Had to contact the Paddle support and they told me they thought our app will be offering services and since it is not allowed in their rules, the account got temporarily suspended.

So having enough pain already I decided to search for WAVE + STRIPE and found the pull commit of magarrent too.

The initial testing caused me some troubles but they were not a result of the code, but my initial setup with Stripe. Bear in mind that if you login as a user, visit subscriptions in the profile and you see Error 500, then you did not set a test user inside of Stripe.

I've discovered a small issue where if the Username is disabled in the settings, the form shows correctly inside of welcome.blade.php and it passes the needed information, however the complete controller is still trying to save the username.

I believe the issue is that we have a check inside of the controller to a0pply the correct validation for settings WITH or WITHOUT username, however later we are trying to resolve what is the username from $request->username.

This should be easy to fix by adding an extra check for the auth.username_in_registration and if set to NO, to define some standard value for username that would be save to the DB.

This worked for me and problem solved for any of the Username options:

        // Update the user info
        $user = auth()->user();
        $user->name = $request->name;

        if(setting('auth.username_in_registration') && setting('auth.username_in_registration') == 'yes'){
            $user->username = $request->username;
        } else {
            $user->username = '';
        }
        
        $user->password = bcrypt($request->password);
        $user->save();

The only thing I've noticed, but have to double check and confirm it is that if the settings of the SAAS allow users to register and then if decided to pay for PREMIUM subscription, the payment success response is redirecting still to the welcome page instead of pointing to the PLANS or elsewhere.

I will check it and get back as I've ran multiple tests and might have touched something I should not ;)

So far so good, the sandbox works perfectly after the initial setup and I must admit that Stripe support is much faster and to the point than Paddle so far.

Of course, another fix can be to add a Else condfition to welcome.blade.php where we check for auth.username_in_registration which would define the username as '' and set the form field as hidden. This way the controller won't complain either, but I believe through the controller is a better option as during custom designs we might forget about the hidden field and remove it from the view :) In case someone is interested, here is the little fix that worked on my side nicely too after resetting the controller to its previous condition:

@if(setting('auth.username_in_registration') && setting('auth.username_in_registration') == 'yes')
	<div class="mt-6">
		<label for="username" class="block text-sm font-medium leading-5 text-gray-700">
			Username
		</label>
		<div class="mt-1 rounded-md shadow-sm">
			<input id="username" type="text" name="username" value="@if(old('username')){{ old('username') }}@else{{ auth()->user()->username }}@endif" required class="w-full form-input">
		</div>
		@if ($errors->has('username'))
			<div class="mt-1 text-red-500">
				{{ $errors->first('username') }}
			</div>
		@endif
	</div>
@else
	<input id="username" type="hidden" name="username" value="test">
@endif

During tests for a registered user to go to Settings>Subscriptions I get a 500 Server error response:

[2022-08-13 17:04:55] local.ERROR: Call to a member function onGracePeriod() on null (View: C:\OpenServer\domains\wavestripe.lar\resources\views\themes\tailwind\settings\partials\subscription.blade.php) {"view":{"view":"C:\\OpenServer\\domains\\wavestripe.lar\

Here is the line 20 where this error is triggered:

@if (auth()->user()->subscription('default')->onGracePeriod())

Now I need to figure out how to handle a newly registered user that is not yet subscribed to any plan and checks subscriptions to avoid the error.

Tried to use:

@if (auth()->user()->subscription('default')->canceled()) {
    @if (auth()->user()->subscription('default')->onGracePeriod())

However the cancelled function also returned null.. Most likely there is no resolving of auth()->user()->subscription('default')...

As expected, the Auth::user() returned the correct record, however Auth::user()->subscription('default') returned null.

Seems like we are not checking if the user even have a subscription before checking if one is on grace period (cancelled but not expired yet)...

Adding a check first if the user has a subscription seemed to prevent the error and show the view correctly:

 @if (auth()->user()->subscription('default'))

Having that said, the info screen now says that I am on a trial period which is not true if a user is allowed to register and then can pick a plan and register based on the needs...

This should be now easy to follow with a few extra checks to advise that there are no current subscriptions and then to show the plans button etc.

OK, the logic got fixed, and all that is left now is to figure out how to return to another ROUTE if the user has already been logged as it is currently showing the registration form again with the name and password to enter instead of a THANK YOU FOR SUBSCRIBING screen and get back to Settings->subscription maybe.

So far so good and it worked perfectly too with the settings after my local user got a subscription... :)

Will have to also test the onGrace to see if it works, but will be later on..