-
Notifications
You must be signed in to change notification settings - Fork 57
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Problem with billing API - Transaction not created in the db #254
Comments
Hi @Benoit1980. $customer_subscription_id = $payloadData['data']['subscription_id']; This seems incorrect? You're trying to lookup a customer record by a subscription ID? Shouldn't it be: $customer_subscription_id = $payloadData['data']['customer_id']; |
Thanks I will check on this tonight and post back. |
Hi @driesvints, I have done a lot of testing. And added these loggers here: The issue lies in the fact that the query "$billable->transactions()->create" never executes when a customer subscribes and pays via Paddle billing in the live environment, although it functions as expected in the billing sandbox. The log entries for Logger('1') and Logger('2') are successfully recorded. However, Logger('3') is never triggered during live Paddle transactions. Consequently, the transaction records are not created, leading to subsequent request failures.
I checked the payload the customer_id is there: This is the part I am not understanding:
What could be causing this code to fail? Users are registering for my app without undergoing any trials or making payments initially. Subsequently, they input their email addresses in the Paddle popup to pay for their first subscription. Is it possible that this workflow might be causing compatibility issues with your package? This is how they are being subscribed at the checkout:
This issue has been difficult, it's preventing the launch of my app. I am surprised for the live environment to encounter failures after successful testing in the sandbox. Thanks again Ben |
This shouldn't be possible. The Which email is being attempted to register? Can you compare the id of the customer you find in production with the ID of the customer in the payload from above? Is it the same or not? |
Hi @driesvints , I wanted to test it tonight but the Hsbc AIS is down tonight. I will retest in the morning. Sorry about that! Best, Ben |
Hi @driesvints , Let me detail all the steps clearly so we know exactly what is happening: SANBOX TEST The payload contains: The paddle response from the POST request is "ctm_01hm6tjcbgbq0k4r6rhcmn8nvw" Upon paying with the fake bank card and clicking on the "SUBSCRIBE" button, 3 tables are filled with records: The paddle transaction.completed event returns: So for the sandbox, everything works as it should ##################################################################################### LIVE TEST The payload contains: No paddle response like with the sandbox showing the customer ctm_number, but I see this in the messages array of the data object(but the user exist in the Paddle billing back end, in the customers area "https://vendors.paddle.com/customers-v2"):
Upon paying with the real bank card and clicking on the "SUBSCRIBE" button, the 3 tables are NOT filled with records: Now here is the weird part: I'm quite surprised to see that the customer's ctm_number before paying is identical for both live and sandbox Paddle requests. Although I used the same email for both tests, I anticipated that the ctm_numbers would be different. I did an extra test, and went in Paddle billing >> Customers >> Click on "[email protected]" And can see: Which matches the customer_id from the transaction.completed but does not match the originator customer['id']. Thanks, Ben |
I'm gonna just note that this is impossible. A sandbox and live environment can't produce the same ID's. There's something very odd going on with your live installation that you're getting sandbox ID's for customers. I suggest you contact Paddle because this is not something we can help with sorry. |
Ok @driesvints , I will speak to them now and see what is going on. Thanks again for your help. |
Alright, I've understood the issue now. Upon Paddle's notification about the wrong continued use of the SandBox ctm_id, I found that the records were indeed in the database. Initially, I presumed that the ctm_id was fetched by your packages via a single API call using the user's email address. However, it appears that it's saved in the database just before the initial order. Please check the "customers" table: When testing the website with an email such as [email protected], and subsequently attempting a real purchase with the same email/user, the ctm_id fails to update with the live ctm_number. This limitation is why I could get the sandbox to function but not the live mode. I believe a possible solution to address this issue is to introduce an additional column named "paddle_sandbox_id." When the ENV PADDLE_SANDBOX is set to true, this ID would be utilized during the following sandbox process: $user->checkout('pri_01hm7xxxxxxxxxxxxxxxxxxx')
->returnTo(route('dashboard.thankyou')); This feature would allow users of the package to seamlessly transition from a sandbox to a live environment. What I also tried: Integrity constraint violation: 1048 Column 'name' cannot be null (Connection: mysql, SQL: insert into I hope this will help other users who may encounter the same issue. Thanks, Ben |
Hello, |
Hi Movicat, Oftentimes, when encountering significant issues, it becomes necessary to place your site under maintenance and conduct a fake purchase as an admin on your actual live account. This scenario has occurred frequently in my experience with gateways, working with numerous clients. Particularly in urgent situations where time is of the essence, it's not always feasible to undergo the entire testing sandbox process on a secondary account. Additionally, not all accounts on a server are identical. While one account may have the necessary web socket permissions (e.g., Account A), another account (e.g., Account B) might have firewall restrictions or encounter issues with services like Cloudflare or mod_security. Due to these variations, I never assume that a sandbox account will only be utilized for local environments only. I've encountered such situations on multiple occasions where problems had to be fixed in less than 1 hour and lucky we had a paypal sandbox that could work on the spot. Thank you, Ben |
@Benoit1980 you're using sandbox data in your production database. That can never work. You need to use a clean database in production. |
I'm used to working with various technologies like PrestaShop and WordPress, where transitioning from a sandbox to a live account is seamless. However, I understand that this package isn't tailored for such transitions. |
Cashier Paddle Version
2.4.0
Laravel Version
10.48.4
PHP Version
8.1
Database Driver & Version
10.6.17-MariaDB
Description
I'm encountering discrepancies in the behavior of my application when using the Paddle Billing API between the sandbox and live environments. While the hooks from Paddle return OK responses in the live environment, records are not created in the database but are created in the sandbox environment.
Steps To Reproduce
Hello,
I've encountered a strange issue that I'm currently investigating. I've reached out to Paddle for assistance, and they are also actively looking into it.
I've implemented a PaddleEventListener. This listener is essential because it allows me to credit users' accounts promptly upon the completion of transactions. I've opted for the WebhookHandled event to ensure immediate crediting as soon as transactions are finalized.
Here is the code:
eventServiceProvider.php:
My paddle listener:
After digging further, I have noticed that the query $this->findCustomer($customer_subscription_id); fails because no records are created for the transaction in the database, therefore, it is impossible to find the billable_id of the record.
The transaction.completed call back works from Paddle:
I added xxxxxx at different places as I was not sure if I could share all the records from a live card.
The strange part is that none of the hook fail on the live paddle side apart from the last transaction.completed because it cannot find the record:
No records in the table transactions, subscriptions or subscription_items on live purchase, but all filled on sandbox.
We have checked the 2 Paddle accounts, all the records match, the webhook urls too. We are testing this on a remote server(.com domain).
I was expecting numerous hooks to fail when the records are not inserted in the DB.
Thank you,
Regards,
Ben
The text was updated successfully, but these errors were encountered: