• Resolved Puvox Software

    (@puvoxsoftware)


    we have a long-standing, unresolved issue and we ask to redirect this ticket to someone more capable of understanding this very simple and resolvable issue.

    so, Woocommerce subscriptions plugin (without any extra plugins or complexities), we set up a simple subscription product, eg. 4$/month.

    but :

    this problem has been alraedy for more than year, and still not solved. in the past a support guy told that your WPP (Woocommerce Paypal Payments) was unable to do that very simple thing (to allow user to pay with paypal for a subscription) because of one of these:
    1) “subscription product is not connected to subscription plan created in paypal dashboard” – very inadequate statement, because we have random-priced subscriptions and it’s totally impossible we could create the individual plans in paypal dashboard for each of them, or manage them in paypal !

    2) “maybe automatic payments are required by you” – no, we don’t need automatic payments. we have enabled Manual Payments:.

    sif person selects 1 month, “PAY” button should just lead to charging 4$. if user selected 1 year, then 4*12= 48$ should be paid, TOTALLY SAME AS IF Y OU ARE PURCHASING A REGULAR PRODUCT WITH COSTS 48$ !! and we would

    3) “maybe paypal vault is not enabled for account” – we don’t need a vault. we just want manual payments as if customers are purchasing a regular product from our side. indeed, they are purchasing regular product, which is just “12 months for X service” – a fixed price ! we dont need to renew on behalf of users

    We have did all instructions shown across multiple Woo Help pages:

    • Activated Paypal Plugin
    • set USD as currency
    • enabled “Manual subscriptions”
    • enabled mixed payments (neither disabling it changes smth)

    https://imgsh.net/i/a7b648304a

    but nothing helps.

    WHY can’t you understand the very simple thing – we are “selling something for X dollars” and it is not paypal’s business to enforce some “modes” on my side – it does not matter to paypal whether we sell a PHYSICAL/VIRTUAL PRODUCT or SUBSCRIPTION or whatever – we just want user to charge X dollars and what we deliver them (either product or subscription or whatever) it’s our business and matter. so we can’t understand why can’t we achieve this very simple thing, that when cart costs X dollars (eg 48 dollars) we just want paypal payment to be made for 48 dollars (like simple product) and that’s all !!

    please update your plugin to support this simple mode.

Viewing 5 replies - 1 through 5 (of 5 total)
  • Thread Starter Puvox Software

    (@puvoxsoftware)

    when I manually try to simulate “Debit card” payment (instead of paypal button),: https://imgsh.net/i/be669857d7

    i see this error in browser console:

    Request URL : https://www.paypal.com/v1/billing/subscriptions
    Request Method : POST
    Status Code : 400 Bad Request
    Request Payload: {plan_id: “”}

    Response: 

    {
    "name": "INVALID_REQUEST",
    "message": "Request is not well-formed, syntactically incorrect, or violates schema.",
    "debug_id": "***",
    "details": [
    {
    "field": "/plan_id",
    "value": "",
    "location": "body",
    "issue": "INVALID_PARAMETER_SYNTAX",
    "description": "The value of a field does not conform to the expected format."
    }
    ],
    "links": [
    {
    "href": "https://developer.paypal.com/docs/api/v1/billing/subscriptions#INVALID_REQUEST",
    "rel": "information_link",
    "method": "GET"
    }
    ]
    }

    but again, it shouldn’t be in any way “plan -related” paypal shouldnt matter whether it’s plan or simple product. I just want regular payment process to be started.


    Plugin Support Krystian Syde

    (@inpsydekrystian)

    Hello @puvoxsoftware

    I understand the frustration here, so let me walk you through what is actually happening on the PayPal side and what is currently possible with the plugin.

    The core of the issue is how WooCommerce Subscriptions communicates with PayPal when a subscription product is in the cart. Even if you configure the subscription for manual renewals only, the Subscriptions plugin still flags the checkout as a subscription-based purchase. Once that flag is present, the plugin attempts to create a PayPal subscription object through the v1 billing API. That is where the plan_id field comes from in your console logs. With manual renewals there is no plan, so the API call fails.

    When using the Classic Checkout and the “Save PayPal and Venmo” option is enabled, the plugin bypasses this subscription API flow and performs a normal single-charge order. That is the only mode today where PayPal Payments behaves the way you want: subscription product treated as a simple one-time purchase with X dollars collected.

    On the Block Checkout this is currently not possible. The block hides the PayPal redirect gateway intentionally when subscriptions are present because most sites rely on automatic billing and would end up with an invalid PayPal setup. This is the limitation you are running into. The result is what you illustrated on your screenshots: PayPal appears disabled.

    To summarise the current working path for what you want:

    1. Use Classic Checkout instead of the Checkout block.
    2. Enable “Save PayPal and Venmo” in the plugin settings.
    3. Keep your subscriptions on manual renewals.

    This forces the plugin to treat the transaction as a normal single-payment order without any subscription or plan integration on PayPal’s side. That is why your earlier tests worked only in this mode.

    I agree that the manual-renewal subscription workflow should not require a customer-side plan or PayPal vaulting. This is a valid improvement request and has already been forwarded internally. The intention is to make manual-renewal-only subscriptions behave identically to simple products, including full compatibility with Block Checkout.

    Kind Regards,
    Krystian

    Thread Starter Puvox Software

    (@puvoxsoftware)

    thanks for the reply!
    so you should make that improvement (and also make it more intuitive, in needed your detailed reply to understand how can i achieve the goal, spent so much time).

    another thing, i can’t understand, none of other payment processors require that user created dozens of plans in their websites. how that is not a ridicilous? we setup bunch of subscriptions in our website (woocommerce) with very variable/dynamic prices, discounts, etc… it’s just impossible that we setup those plans in paypal dashboard. is not there any way that we create subscription and also use “autmatic renewal” without having paypal subscription package re-created for that specific subscription? it just doesn’t make sense. why/how can we ditch it and just have subscriptions on our website, and did business that way, without need to setup any plans in paypal dashboard.

    Plugin Support Krystian Syde

    (@inpsydekrystian)

    Hello @puvoxsoftware

    Regarding the suggested improvement, the main challenge is that this is a very niche scenario. If I remember correctly, we have only had two or three tickets describing a similar use case. We’ll try to make it more intuitive, but in q1 2026.

    Concerning your second point, I assume you are referring to the PayPal Subscriptions API and the requirement to manage plans in the PayPal dashboard. In your specific case, you should not really need to rely on that model at all, as suggested in my previous response. For setups with highly dynamic pricing, discounts, and variable subscription terms in WooCommerce, the correct approach is to use vaulting with rather than PayPal Subscriptions.

    With vaulting, the subscription logic, pricing, discounts, and renewals are handled entirely by WooCommerce. PayPal is only used to securely store the payment method and charge it on each renewal. This avoids the need to pre-create plans in the PayPal dashboard and removes the limitation you described. The PayPal Subscriptions API, including plans, is a PayPal side requirement and behavior. We only implement the integration in the plugin and do not control how that API works.

    Kind Regards,
    Krystian

    Plugin Support Krystian Syde

    (@inpsydekrystian)

    Hello @puvoxsoftware

    Since we have not received any further communication from you, we are assuming that your issue has been resolved. Therefore, we mark this thread as resolved.

    If you have any further questions or encounter a new issue, feel free to open a new thread or submit a ticket through our service desk. Please include the URL of this thread in your ticket for reference.

    Kind regards,
    Krystian

Viewing 5 replies - 1 through 5 (of 5 total)

You must be logged in to reply to this topic.