Forum Replies Created
-
Posts
-
If you do a translation of the plugin, you should have that text be shown in your language:
The short answer is “No”. Payment gateways doesn’t really have a way to handle this since a user can always use a different card (or use a family member) to do a transaction.
The main way to handle this would be to charge a small amount for the trial (to only attract legitimate users). When you are offering something free, you have to be prepared for some users who will not act in good faith. So factor that in when you price your items.
Another option is to add a membership layer to your site. Something like our following plugin:
Then you will have users who are creating account on your site. You can then manually see which member accounts are doing what and then block an account accordingly.
Something else is going on there. That error is not supposed to show as a 500 error. The error is being triggered by the Stripe’s library (that is given to us by Stripe). Are you using the latest version of our plugin and any addons (to make sure the latest Stripe library is being used)?
Post the URL of the page where the payment button is so I can inspect a couple of things using my browser.
Something else on this server is preventing the plugin from fully completing the process that’s why you are seeing an abnormal behavior. The server’s error log will have more details as to what it is complaining about. So look at the server’s error log file immediately after the Error 500 is triggered by the server. The latest entries in that error log file will have clues as to what is failing. The message in the error log file may look cryptic, if you share the error messages from that file, we should be able to read it and provide help.
This looks like a plugin conflict related issue. Please do the following test:
Test for Plugin and Theme Conflict Before Posting an Issue or a Bug
For that feature, the transactions need to be made while being logged into the site (so the plugin can recognize a user and store the transaction data for that user). Are you testing with an account where the transaction was made after the user logged into the site?
If you are just allowing anonymous checkout (guest checkout), then the plugin won’t have any idea in terms which user is purchasing what.
Enable the debug logging option in both the Stripe plugin and the emember plugin. Then do a test transaction with a user account that you created (for testing). Does that transaction show correctly?
Fully read the following documentation which should be helpful for you:
You can add an email merge tag that will add a “cancellation link” in the sale notification email (when they do the transaction). The customers can use that cancellation link to unsubscribe when they want (without contacting you).
You are looking at the “payments” tab in Stripe. That won’t have the info you are looking for. Go to the following interface in your Stripe account:
Customers -> Subscriptions
Then click on a customer and it will show you the item the subscription is for.
Also, you can look inside our plugin’s “subscriptions” menu. Click on the “View details” link for a subscription and it will have additional details. The link in the “ID” column takes you to the page in Stripe that has more details also.
Coupons are applied in the payment popup window. Check the following documentation:
This is not something our plugin can do. You may want to put a message on your landing page (near the payment button), explaining which area you will accept (so people clearly know this information before they click the button).
Enable the debug log option in the settings then do a test transaction:
Using the Debug Log to Solve Transaction Related Issues on a Site
Do you see any error in the log or indication of any failures?
Is your site using any caching?
