[alexanderfoxc]

Can you please get in touch via the contact form https://s-plugins.com/contact-us/?

We might need to check this on your site.

[alexanderfoxc]

Hi.

This is not possible at the moment.

However, you have provided a good use-case scenario, so we’re going to implement this functionality in the multi-currency add-on.

The way I see it: there should be a new option in the add-on settings, called “Default Currency”. Using this option, you’ll be able to specify which currency everything should be converted to by default. In your case, that would be BRL.

[alexanderfoxc]

Hi Danielle.

Subscriptions add-on supports setup fee for the plans. So you can achieve what you want by following:

1. Create 3 plans (for $100, $200 and $300 respectfully) with $900 setup fee (your base product price) each.

2. Attach these plans to your products.

3. Create a page where your customers can select the product they want. You can place 3 product buttons on that page using shortcodes (or attach them to existing buttons).

[alexanderfoxc]

Please try new testing version https://s-plugins.com/testing-version/

It should finally deal with the issue when payment popup is cached by WPEngine.

Let me know if this helped.

[alexanderfoxc]

Thank you.

I can see on your site now that payment popup is no longer cached by WPEngine, so the temporary solution that I have implemented seems to be working.

We’re currently working on a better solution to this (and all caching-related issues in general). I’m going to ask you to install another testing version when it’s ready (most likely within couple of days from now).

Will keep you posted.

[alexanderfoxc]

Hi.

This looks to be related by WPEngine caching indeed. I have implemented some measures in the code that should hopefully get this issue resolved.

Can you please install current testing version of the core plugin https://s-plugins.com/testing-version/ and let me know if this helped? Make sure to clear all WPEngine caches after you install it.

[alexanderfoxc]

Subscriptions add-on version 2.0.29 has been released. It has this functionality implemented.

All the recurring payments that were made after you install this version will have following description: Product name (x of y).

[alexanderfoxc]

Subscriptions add-on version 2.0.29 has been released. It has this issue fixed.

[alexanderfoxc]

Hi and thank you for your input.

There are no Stripe API limitations for this (at least none that I know). The reason why this wasn’t implemented is the idea to keep Stripe API requests at lowest level possible. However, I can see this can be implemented via webhooks. It would require one additional API request per each installment payment, but since it’s gonna be made asynchronously (without slowing down or affecting customer’s experience), I think this could be done.

Will research this and get back to you.

[alexanderfoxc]

Hi and thank you for your report.

This is a bug indeed. Good thing is that get_cancel_link() function you mentioned is currently used by [asp_show_my_transactions] shortcode only, so it does not affect any other parts where the cancellation URL is used (email merge tag, subscription details page etc).

This will be fixed in the upcoming version of the Subscriptions add-on.

[alexanderfoxc]

Hi and thank you for your report.

The reason why 5 or 6 subs were created is because of the minimum amount in JPY. It is around 50-60 JPY (depends on the JPY/USD exchange rate, should be 0.5 USD minimum), but your test plan was for 10 JPY. So instead of showing an error that the amount is below minimum, Stripe kept creating subscriptions until minimum amount is reached – e.g. 5-6 subs x 10 JPY = 50-60 JPY, which is the minimum amount.

I have created a new TEST mode plan, but made the price 100 JPY and now it’s working fine, please check yourself.

We will add the error message when creating a plan if the amount is below minimum.

Apologies for the inconveniences you had to face due to this and thank you very much for reporting it.

[alexanderfoxc]

Made 2 test payments – one via Google Pay and one via SOFORT. Both went through fine, also received success emails from the site (not Stripe receipts though – it does not send emails in test mode).

The issue for your customer could be caused by errors on the page like I mentioned earlier. Open Chrome Dev Console (F12) and make sure there are no errors there (especially related to JavaScript and HTTPS). On some browsers\devices those errors could mess up payment process, which could cause various random issues (like Apple\Google Pay buttons not displayed, payment process stuck etc.).

[alexanderfoxc]

Thank you.

SOFORT will not be offered as payment option until EUR is selected as currency. Try to change currency to EUR and see yourself.

Google Pay (which is using exactly the same code as Apple Pay) is displaying fine for me as well. If you can create a test product (with “Force Test Mode” option enabled), I’m happy to make a test payment.

Try to clear your browser cache and see if it helps.

There are also some issues on the page which should be addressed (those could be the reason why it’s not working for you as well). For instance, this is what Chrome Debug Console shows:

(index):1 GET https://34.245.179.213/wp-content/themes/mesmerize/assets/images/home_page_header.jpg net::ERR_CERT_AUTHORITY_INVALID

[alexanderfoxc]

Hi.

I cannot reproduce the issue – both SOFORT and Google Pay buttons are displayed fine on my test site.

Can you share a link to the page where you payment button is so I could have a closer look?

[alexanderfoxc]

Hi Bjorn and thank you for your report.

This has been fixed in iDEAL add-on version 1.0.10. Please update it on your website via WP Dashboard -> Updates.

I apologies for inconveniences this might have caused.

[Author]

Posts