PaddleHQ / paddle-js-wrapper

Wrapper to load Paddle.js as a module and use TypeScript definitions when working with methods.
Apache License 2.0
28 stars 4 forks source link

[Bug]: Invalid types usage with typescript for subscription based checkout #18

Closed avallete closed 4 months ago

avallete commented 6 months ago

What happened?

When opening a "Checkout" based over a "subscription" planId, while it's possible to do it, the types will throw an error.

I had several errors and differences between types definitions and actual values needed by the app.

Steps to reproduce

  1. Typescript + npm install @paddle/paddle-js
import { initializePaddle, Paddle } from '@paddle/paddle-js'

initializePaddle({
      seller: <vendor-id>, // This will satisfy the types, but will raise an error in the console: "Paddle Initialization failed. Please check the inputs Error: [PADDLE] You must specify your Paddle Vendor ID"
      environment: 'sandbox'
}).then((paddleInstance) => {
    if (paddleInstance) {
        // This call will work and open the desired checkout box, but the types will complain
        paddleInstance.Checkout.open({
            product: <subscription-plan-id>, // This will throw a type error in the types asking for "items"
            successCallback: async (data) => { // This will throw a type error saying the property doesn't exist 
               mycallback(data)
            },
        })
    }
})

What did you expect to happen?

The types and runtime behaviour to match each others.

How are you integrating?

No response

Logs

No response

vijayasingam-paddle commented 6 months ago

Hi @avallete, Based on the inputs you are passing to the checkout and the error message it returns, it looks like you are trying to launch a Paddle classic checkout using this library.

This library is built for paddle billing and unfortunately, will not work with paddle classic. We do not have a typescript library for paddle classic and you will have to implement it with vanilla Javascript. Please refer to this documentation for more details.

Please let us know if you need any help.

Thank you.

avallete commented 6 months ago

Alright it make a lot more sense, thanks for the answer.

It seems indeed that I'm interfacing with "paddle classic". As a follow up question, I'm now wondering, if this approach is the best to achieve what I want to do (checkout payment based over a subscription plan id) or if there is some ressources describing a better alternative using the paddle billing approach.

heymcgovern commented 5 months ago

Hey @avallete šŸ‘‹ Michael from the DX team here

Paddle Billing is built on top of the Paddle platform, but it has its own data that's totally separate from Paddle Classic. If you're working with Paddle Classic, you can't use the Paddle Billing API or developer tools to interface with your Paddle Classic data.

If you'd like to try Paddle Billing, you can opt in without impacting your Paddle Classic data. Once opted-in, you'll get access to a toggle that lets you switch between Billing and Classic. You can learn more about Paddle Billing and how opting in works on our docs: Paddle Billing: What you need to know

You don't need to move to Paddle Classic just yet, and you can continue using Paddle.js v1 and the Paddle Classic API to work with Paddle Classic. For the future, we're actively working on a path for migrating from Classic to Billing. If you're interested, I can pass your details along to the team who are heading up migrations ā€” we'd love to hear more about how you use Paddle and get your thoughts on what the migration process might look like šŸ˜„

avallete commented 5 months ago

Hey @heymcgovern

Thank's for clarification. We are just starting implementing payment in our product so it was a blank slate, but I guess our issue was that we registered to Paddle account a while ago therefore we we're automatically put on the "paddle classic" version.

I don't know where to report this, but implementing webhooks via the "classic api" seems to have a difference between the api reference and the actual behaviour. For the subscription_created event the docs mention that they should be some cancel_url field to save along with the customer informations on our side however here is what I received on the webhook listener side:

{
 alert_id: '8334186',
 alert_name: 'subscription_created',
 checkout_id: '1881710-chreffa45a62785-bb6beab537',
 currency: 'USD',
 custom_data: '{<...>}',
 email: '<email>',
 event_time: '2024-01-15 16:48:19',
 linked_subscriptions: '',
 marketing_consent: '0',
 next_bill_date: '2024-02-15',
 passthrough: '<...>',
 quantity: '1',
 source: 'localhost:8910 / localhost:8910',
 status: 'active',
 subscription_id: '638763',
 subscription_plan_id: '10940',
 unit_price: '0.00',
 user_id: '708577',
 p_signature: '<...>'
}

That caused me issue when trying to setup the "cancel subscription" behaviour.

I ended up re-creating a new account over paddle sandbox to try the implementation with the "paddle billing" product. In the meantime feel free to close this issues as this github repo doesn't seems like the right place to report this kind of issues (paddle classic). But if there is some paddle community discord / slack where we can report and ask questions about how to setup payment with paddle I'll happily join in !