arlyon / async-stripe Goto Github PK

I can see the CheckoutSession struct but it doesn't appear to have the ability to create one. Am I missing it somewhere or does it just not exist? Thx.

Hey, I want to expose the ephemeral key interface by adding the appropriate few lines of code in generate.rs and resources.rs. Since it's used in conjunction with payment_intents and setup_intents, my intention is to add it to the "core" functionality.

Is it okay, if I do this and get this pulled into mainline after?

Hi first of all thank you very much for the stewardship of this library,
Quick question, trying to use the connect features I can see that these types are overriding actual useful generated types, that allows the Account creation call to be made.
Not sure if that was left as a placeholder for the future in which case:

• I would change the feature from "account" to "connect" as "account" feature is not present anymore;
• or if it just needs to be removed --this is what i would probably do-- but i don't understand the library in depth so just requesting your advice.

Thanks again

Now that tokio and hyper have reached 1.0, it would be nice to support them.

For anyone considering using this library, here is a rough list of changes that I have made (for what I would consider to be the better) compared to wyyerd/stripe-rs

• pluggable async backends, so it is compatible with tokio and async-std #5
• reworking of generation script to be faster, more resilient, and work with the new documentation format
• add previously missing methods to the generation script #33
• move all generated code to the generated folder to differenciate better #5
• github actions to regenerate the definitions every week automatically #11
• move over to using cargo-make to handle the scripting #5
• drop travis in favour of github actions #5
• simplify testing using docker #5
• tokio 1.0 support #28
• stop using internal serde apis #26
• simplify error handling and remove uneeded variants using thiserror #38

API requests will be closed to keep the issue tracker clean and the issue will be added to this list. If it is unchecked, it is unaddressed. Any PR's addressing these will be handled speedily (I promise! 😄 )

• setup_intent_ext (#41)
• Customer balance transaction API (#271)
• Search customer API (#260)
• Balance::retrieve (#280)

The library is in a good place. Here are some things we'd like to get done before 0.13.0:

• port the tokio and hyper code to support 1.0 (#1)
• review the API and make sure we aren't missing things from the old API
• automatically update the openapi spec
• remove all unwraps from the code (#20)

We have a few ways of determining 'overall health' of the project, only some of which are actually in use:

• cargo make verify: a simple shell script that picks out unexported apis
• cargo make duplicates: some script to detect duplicate names across files
• bench/binary_size: a benchmark that was historically used to track build times

It would be great to get these automatically running on the weekly openapi CI, and reporting build times, artefact size, and unexported apis in the PR. This Issue tracks that progress.

I fixed this problem and I've submitted a pull request. The good news is that the general interface I built for card, seems to work for this as well. This is beyond encouraging. Anyway, the transfer API can now be used.

Hey, I noticed a lot of new commits coming in and I was wondering when they would be pushed to crates.io. Specifically looking to pick up the change where the card field was added to CreatePaymentMethod.

Just letting you know as a favor, unions around anyof types are broken. Stripe apparently doesn't acknowledge their existence within any type of struct both sending and receiving. That means that things like PaymentIntents break under the right conditions. Right now I'm having issues with Payment Intents when a card is the payment method (deserialization fails).

Hi.

I have tried multiple times (cargo clean -> cargo c), but always got the compiler error.
Either: (signal: 11, SIGSEGV: invalid memory reference), or other error such thread 'rustc' panicked at 'index out of bounds: the len is 10766 but the index is 2147484856',

Is this only happen in my end?

❯ rustc -V
rustc 1.52.1 (9bc8c42bb 2021-05-09)

async-stripe on  master [$] is 📦 v0.13.0-rc3 via 🦀 v1.52.1 took 21m35s
❯ cargo c
   Compiling num-traits v0.2.14
    Checking num-integer v0.1.44
    Checking chrono v0.4.19
    Checking async-stripe v0.13.0-rc3 (/home/user/playground/async-stripe)
thread 'rustc' panicked at 'index out of bounds: the len is 10766 but the index is 2147484856', compiler/rustc_span/src/symbol.rs:1619:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

error: internal compiler error: unexpected panic

note: the compiler unexpectedly panicked. this is a bug.

note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md

note: rustc 1.52.1 (9bc8c42bb 2021-05-09) running on x86_64-unknown-linux-gnu

note: compiler flags: -C embed-bitcode=no -C debuginfo=2 -C incremental --crate-type lib

note: some of the compiler flags provided by cargo are hidden

query stack during panic:
end of query stack
error: could not compile `async-stripe`

Caused by:
  process didn't exit successfully: `rustc --crate-name stripe --edition=2018 src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="billing"' --cfg 'feature="checkout"' --cfg 'feature="chrono"' --cfg 'feature="connect"' --cfg 'feature="default"' --cfg 'feature="events"' --cfg 'feature="fraud"' --cfg 'feature="full"' --cfg 'feature="hmac"' --cfg 'feature="issuing"' --cfg 'feature="orders"' --cfg 'feature="sha2"' --cfg 'feature="sigma"' --cfg 'feature="webhook-endpoints"' --cfg 'feature="webhook-events"' -C metadata=d384d8648156eefe -C extra-filename=-d384d8648156eefe --out-dir /home/user/playground/async-stripe/target/debug/deps -C incremental=/home/user/playground/async-stripe/target/debug/incremental -L dependency=/home/user/playground/async-stripe/target/debug/deps --extern chrono=/home/user/playground/async-stripe/target/debug/deps/libchrono-0b18a506feaf800c.rmeta --extern hmac=/home/user/playground/async-stripe/target/debug/deps/libhmac-de42eb50dff098ea.rmeta --extern serde=/home/user/playground/async-stripe/target/debug/deps/libserde-96ff4cf191e06faa.rmeta --extern serde_derive=/home/user/playground/async-stripe/target/debug/deps/libserde_derive-11e136bb03edb9ee.so --extern serde_json=/home/user/playground/async-stripe/target/debug/deps/libserde_json-9bd9a6a16456798e.rmeta --extern serde_qs=/home/user/playground/async-stripe/target/debug/deps/libserde_qs-311f90b064b42263.rmeta --extern sha2=/home/user/playground/async-stripe/target/debug/deps/libsha2-d6b53bfa93fd5ad3.rmeta --extern smol_str=/home/user/playground/async-stripe/target/debug/deps/libsmol_str-db719f92a5b5c191.rmeta --extern thiserror=/home/user/playground/async-stripe/target/debug/deps/libthiserror-310b2d26a6f7e4c8.rmeta` (signal: 11, SIGSEGV: invalid memory reference)

async-stripe on  master [$] is 📦 v0.13.0-rc3 via 🦀 v1.52.1
❯ cargo c
   Compiling proc-macro2 v1.0.27
   Compiling typenum v1.13.0
   Compiling version_check v0.9.3
   Compiling unicode-xid v0.2.2
   Compiling autocfg v1.0.1
   Compiling syn v1.0.72
   Compiling serde v1.0.126
   Compiling libc v0.2.96
   Compiling ryu v1.0.5
   Compiling serde_json v1.0.64
   Compiling serde_derive v1.0.126
    Checking subtle v2.4.0
    Checking opaque-debug v0.3.0
    Checking cpufeatures v0.1.4
    Checking cfg-if v1.0.0
    Checking itoa v0.4.7
    Checking percent-encoding v2.1.0
    Checking smol_str v0.1.17
   Compiling generic-array v0.14.4
   Compiling num-traits v0.2.14
   Compiling num-integer v0.1.44
error: could not compile `libc`

Caused by:
  process didn't exit successfully: `rustc --crate-name libc /home/user/.cargo/registry/src/github.com-1ecc6299db9ec823/libc-0.2.96/src/lib.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type lib --emit=dep-info,metadata -C embed-bitcode=no -C debuginfo=2 --cfg 'feature="default"' --cfg 'feature="std"' -C metadata=6135e5f4e746ab40 -C extra-filename=-6135e5f4e746ab40 --out-dir /home/user/playground/async-stripe/target/debug/deps -L dependency=/home/user/playground/async-stripe/target/debug/deps --cap-lints allow --cfg freebsd11 --cfg libc_priv_mod_use --cfg libc_union --cfg libc_const_size_of --cfg libc_align --cfg libc_core_cvoid --cfg libc_packedN --cfg libc_cfg_target_vendor` (signal: 11, SIGSEGV: invalid memory reference)
warning: build failed, waiting for other jobs to finish...
error: build failed

I have been doing some planning on how we can rework the api for 0.15. This will be a minimal outcome for end users but will change the way types are managed and reexported internally to enable parallel compilation.

In 0.14 I split the codegen to work in terms of Files. A file logs all of its dependencies and these are added when the file is written. The goal is to

• expand the import tracking metadata to track the crate it is coming from - initially the crate will just be stripe
• define some metadata on organising crates
• write a crate generating module that will create a cargo file, generate all the dependencies, and add a mod that exports all the items inside it
• resolve dependencies between cargo files (and crates)

Right now we box everything, but we'd be able to improve the API enumerating all the types, then, during codegen, only Box the generated types (those with potential cycles).

I need the ability to make Idempotent Requests as explained here:
https://stripe.com/docs/api/idempotent_requests?lang=curl

The problem is that these requests are a) possible whenever posting regardless of API and b) are put in the header of the request not the data section.

I think the way to implement is to give all "put" requests (create in our current paradigm) an optional Idempotent string value. Unfortunately (or fortunately, depending on who you ask) Rust doesn't support default parameters, so while it will be optional, it will break the top level API. Not much we can do about that though.

I'm working on the implementation now, let me know if you have any objects/comments when you're available.

Duplicate of wyyerd/stripe-rs#165

This code is vulnerable to a timing attack, because the != check takes a different amount of time if more characters from the provided signature are correct.

An exploit over the network is unlikely, but as a best practice this should be a constant-time comparison.

I've found some crates we can use to implement this:

• ring::constant_time::verify_slices_are_equal
• dalek-cryptography/subtle
• crypto::util::fixed_time_eq

@FL33TW00D Brought up a good point about defaults. I think that after the Option, Box switch is made we should try to add the Default tag to the generated structs, just like we do with Debug.

Thoughts?

stripe::UpdatePaymentMethod (and the master branch) seems to be missing the card parameter, to e.g. update an already saved card's expiration without needing to create a new card (with the full number).

Can it be added? (I can try to open a PR). Or am I missing it somewhere else? Is it just because the supported API version is 2020-08-27?

I make a new issue to avoid spamming the subscriber in #32.

Could you please elaborate more ?

Based on my understanding, The path is:

1. fetching stripe open API spec from https://github.com/stripe/openapi/tree/master/openapi
2. feed it to async-stripe/openapi/
3. async-stripe/openapi/ will parse the openapi and write the generated Rust code into out directory.
4. copy the directory into ``async-stripe/src/resources/generated/`

At first I thought it was something like this:

modified   src/resources/generated/token.rs
@@ -99,6 +99,10 @@ pub struct CreateToken<'a> {
     /// The PII this token will represent.
     #[serde(skip_serializing_if = "Option::is_none")]
     pub pii: Option<CreateTokenPii>,
+
+    /// The Card this token will represent.
+    #[serde(skip_serializing_if = "Option::is_none")]
+    pub card: Option<CreateTokenCard>,
 }
 
 impl<'a> CreateToken<'a> {
@@ -110,6 +114,7 @@ impl<'a> CreateToken<'a> {
             expand: Default::default(),
             person: Default::default(),
             pii: Default::default(),
+            card: Default::default(),
         }
     }
 }
@@ -206,6 +211,14 @@ pub struct CreateTokenPii {
     pub id_number: Option<String>,
 }
 
+#[derive(Clone, Debug, Deserialize, Serialize)]
+pub struct CreateTokenCard {
+    #[serde(skip_serializing_if = "Option::is_none")]
+    pub number: Option<i64>,
+    pub exp_month: Option<i32>,
+    pub exp_year: Option<i32>,
+}
+

But I realized it will be overidden by code generation, so is it someting like this:

modified   openapi/src/mappings.rs
@@ -578,6 +578,11 @@ pub fn field_mappings() -> FieldMap {
             ("create_payment_method", "billing_details"),
             ("BillingDetails", "Option<BillingDetails>"),
         ),
+
+        (("create_token_card", "exp_month"), ("Card", "Option<Card>")),
+        (("create_token_card", "exp_year"), ("Card", "Option<Card>")),
+        (("create_token_card", "number"), ("Card", "Option<Card>")),
+
         (("transfer_schedule_params", "delay_days"), ("DelayDays", "Option<DelayDays>")),
         (("transfer_schedule_params", "weekly_anchor"), ("Weekday", "Option<Weekday>")),
         (("create_webhook_endpoint", "api_version"), ("ApiVersion", "Option<ApiVersion>")),

I tried to search for a PR that adds a new feature for me to follow. I want to know what parts need to be changed. Unfortunately, I can't find it. I also checked the git blame, but no still no clue.

after adding the line above (in mapping.rs) I run openapi-install, but I don't see card token addition in src/resources/generated/token.rs. So I must be missing something.

When listing e.g. Prices with the child Product expanded, only the first page of results has expanded Products.

        let page_1 = stripe::Price::list(
            &client,
            stripe::ListPrices {
                expand: &["data.product"],
                ..stripe::ListPrices::default()
            },
        )
        .await.unwrap();
      let page_2 = page_1.next(&client).await.unwrap();

The product field in every element of page_1 is Expandable::Object, while in page_2 every element is Expandable::Id.

I create the stripe Client for a connected account:

    let mut stripe_client = stripe::Client::new(&stripe_configuration.sk_key);
    stripe_client.set_stripe_account(&connected_account.id);

This works well for some function but it fails when I try to do this:

    let stripe_customer = stripe::CustomerId::from_str(stripe_customer_id)?;
    ...
    let setup_intent = stripe::SetupIntent::create(&self.stripe_client, params).await?;

I get this error:

Err(
    JSONSerialize(
        Error("data did not match any variant of untagged enum Expandable", line: 4, column: 54),
    ),
)

This is due to a failure deserializing the application field, whose value is a string, in the response.

I checked that by removing the application field from the SetupIntent struct the problem disappears.

Is that a bug ? Or do I do something wrong ?

Hello,

As I was working on this repo to try and get the loginlink working, I realized that every time I ran the generation code on master the code generation breaks because of updates. I didn't want to push my link to a previous tagged commit (i.e 13-rc3), so I started to look into why code generation was breaking.

The first issue was relatively easy to fix. Quote is a dependency of a type that it implicitly generates and therefore falls into a corner case that incorrectly adds itself as a resource use to its own generated file.

But the second issue is a little bit more intense. Some dependent types that have more than one dependency are skipped to generate. This makes a little bit of sense as they are found inside of a "generated" file so to speak and a naive solution would allow you to have two of the same "type" published from two or more different source directories.

The current solution, seems to be to hand code these types into resources Types.rs. This seems like a non-tenable solution that will cause the generated code to continue to break into the future. I don't like out of date API's especially when this particular version of the OpenAPI is the "stable one" according to git.

So, what if we modified the generated main file to either a) add on these extra files onto the end of the objects metadata field (this would generate a unique file for each, but would require some refactoring because the objects are borrowed immutable in a number of places) or b) create a new category in metadata that runs after the objects and essentially does the same thing as a) but sidesteps the problem of having to add on to a container that is running inside an iterator loop.

Then you would need to remove some of the hand written types that no longer need to exist.

Thoughts?

Some leads:

• https://doc.rust-lang.org/unstable-book/language-features/doc-cfg.html
• https://stackoverflow.com/questions/61417452/how-to-get-a-feature-requirement-tag-in-the-documentation-generated-by-cargo-do
• https://github.com/launchbadge/sqlx/search?q=docsrs

This api is nonstandard by our simple function generation code so it has to be added by hand. I'll add it on top of the idempotent stuff and suubmit a pull request when that happens. Adding the issue here so people know it's on it's way.

While attempting to confirm a SetupIntent to attach a payment method to a customer, it appears the SetupIntent::confirm() method does not exist.

https://docs.rs/async-stripe/0.13.0-rc2/stripe/struct.SetupIntent.html#implementations

See stripe documentation: https://stripe.com/docs/api/setup_intents/confirm

Struct PlanInterval exist multiple places which is causing issue when creating the subscription with a inline price plan:

let recurring: stripe::SubscriptionItemPriceDataRecurring = stripe::SubscriptionItemPriceDataRecurring {
      interval: stripe::PlanInterval::Month,
      interval_count: Some(100),
};

this Gives Error :

 interval: stripe::PlanInterval::Month,
    |          ^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected enum 'stripe::resources::generated::billing::subscription::PlanInterval', found enum 'PlanInterval'    

I tried removing the extra struct in file subscriptions.rs and subscription_item.rs and import on top it's working this way.

Let me know if there is better way. (Will submit the PR with this changes)

Many of the tests currently are using the blocking runtime. Ideally, we will have the tests work on any of the async runtimes, since the blocking module is just a blocking wrapper around hyper.

Hi! I'm trying to run some of the example code and running into a weird error.

Here's the code:

    let client = stripe::Client::new(stripe_api_key);

    let params = stripe::ListCharges::new();
    let charges = stripe::Charge::list(&client, params);
    println!("{:?}", charges);

Here's the error:

Err(JSONSerialize(Error("data did not match any variant of untagged enum Expandable", line: 13, column: 58)))

I'm using this version:

async-stripe = { version = "0.13.0-rc3", features = ["runtime-blocking"]}

I confirmed with the API key the Stripe request works using the CLI. I can also see the Rust queries in the Stripe dashboard succeed with a 200.

It's entirely possible I'm doing something wrong! I'm a Rust newbie.

Hi, I've tried to use your repo as a crate but I run into the following issue:

error[E0603]: module `private` is private
   --> /Users/postman/.cargo/git/checkouts/stripe-rs-3e7b78b77fb3e2b2/d119441/src/resources/payment_source.rs:30:20
    |
30  |         use serde::private::de::{Content, ContentRefDeserializer};
    |                    ^^^^^^^ private module
    |
note: the module `private` is defined here
   --> /Users/postman/.cargo/registry/src/github.com-1ecc6299db9ec823/serde-1.0.119/src/lib.rs:277:5
    |
277 | use self::__private as private;
    |     ^^^^^^^^^^^^^^^^^^^^^^^^^^

    Checking async-graphql v2.4.7
    Checking sqlx v0.4.2
    Checking async-graphql-tide v2.4.7
error: aborting due to previous error

For more information about this error, try `rustc --explain E0603`.
error: could not compile `stripe-rust`

This is my cargo entry for it:

stripe-rust = { git = "https://github.com/arlyon/stripe-rs", branch = "async-std-runtime", features = [ "runtime-async-std-surf" ] }

While building 0.14.0, I noticed that async-std is included as a dependency even when building with one of the tokio runtime features, ex.

$ cargo tree --features runtime-tokio-hyper-rustls
/* snip */
├── http-types v2.12.0
│   ├── anyhow v1.0.53
│   ├── async-channel v1.6.1
│   │   ├── concurrent-queue v1.2.2
│   │   │   └── cache-padded v1.2.0
│   │   ├── event-listener v2.5.2
│   │   └── futures-core v0.3.21
│   ├── async-std v1.10.0
/* snip */

Changing the http-types dependency to be

http-types = { version = "2.12.0", default-features = false }

fixes the issue, but I haven't considered whether this is truly valid or not.

Hi @arlyon, thanks for making this fork!

Besides the async support, could you describe how else async-stripe differs from stripe-rs? Is there support for other API features that are currently missing from the codegen in the stripe-rs project?

Namely, support for:

• idempotent requests, connection pooling, retries
• 2020 API
• Checkout,
• webhooks (also, there's a security vulnerability in the upstream crate)

I'd be willing to help port over any missing functionality that's in stripe-rs and not available in this project yet. Hopefully, Stripe is start supporting an official Rust crate soon...

Hello,

I am trying to figure out if this library uses HTTPS on the backend or if all requests are made through HTTP. It appears as though the client uses surf::Client to make the request, which by default uses curl and not a TLS feature variant. In the Cargo.toml it appears as if there is nothing in there to change to a TLS backed variant of the surf.

This surprises me that Stripe would allow this to happen. Am I reading the code wrong? Can you help point out my mistake if not? I'm hoping to use this library, but I want to make sure the company won't be sued should something occur.

Thanks for your efforts, I think this library is great by the way.

Stripe supports this wonderful new thing called a Test Clock, for placing specific customers into timespaces (my twist on "namespaces"), which can be moved forward by API calls, in order to make Stripe generate webhook requests for things like billing cycle transitions, in simulated time. Test Clocks are currently a beta feature and aren't generally available yet.

I'd like to support this in async-stripe. A couple of questions:

• The API for test clocks isn't present in stripe's openapi spec. Do we need to wait until that changes, or could we add it now behind a cargo flag?
• It seems that the natural place to configure a Test Clock is in the CreateCustomer struct: adding a field test_clock: Optional<TestClockId>. However CreateCustomer is generated from the openapi spec. I did not see a way in our openapi crate to manually add fields to a particular codegen'd struct. Is there a way?

Hi,
I tried to use CreateCheckoutSession while only setting the "checkout" feature in my cargo.toml but I got a compile error saying that Price didn't exist. To make it work I had to add the billing feature. I will give more details when I have more time.
Thanks for this crate!

I mistakenly thought that a Rust trait was needed to extend a type. This turns out not to be true. I need to clean up the random traits I've added to the LoginLinksExt code and the SetupIntent API code.

I'm using the following line in my Cargo.toml:

async-stripe = { version = "0.13", default-features = false, features = ["runtime-tokio-hyper-rustls", "billing", "webhook-events"] }

and this is the compile error I get:

   Compiling async-stripe v0.13.0
error[E0432]: unresolved import `crate::resources::CheckoutSessionItem`
  --> /home/dthul/.cargo/registry/src/github.com-1ecc6299db9ec823/async-stripe-0.13.0/src/resources/generated/quote.rs:11:14
   |
11 |     Account, CheckoutSessionItem, Currency, Customer, Discount, Invoice,
   |              ^^^^^^^^^^^^^^^^^^^
   |              |
   |              no `CheckoutSessionItem` in `resources`
   |              help: a similar name exists in the module: `CheckoutSession`

As far as I can tell CheckoutSessionItem will only be re-exported from crate::resources when the checkout Cargo feature is activated.
As a quick fix I changed my dependency line to:

async-stripe = { version = "0.13", default-features = false, features = ["runtime-tokio-hyper-rustls", "billing", "webhook-events", "checkout"] }

According to the api docs this field is optional, but my workflow needs it available for update.

I tried looking for issues similar to this but did not find anything. I assume there is something mission from the openapi codegen.

I am happy to do the fix if you can point me in the right direction.

Thanks,
Grant

On the original update, when I fixed the infinite recursive type sizes, I made the optionals Box<Option> types instead of Option<Box> types. The second one is more useful in making the code easy to write and more intuitive in the Rust programming space apparently. I'll fix it and make a pull request.

The latest API broke the code from compiling. This was happening for two reasons.

1. The payment intent payment methods have introduced new data structures that do not match the previous standard. This causes us to crash on an unwrap. This was fixed by making the unwrap an unwrap_or_else to handle both the old style of unions and the new style.

2. After solving the first wrapping, we had a problem with duplicate names because our new unions just so happened to share the same name as other structs when they got through the union naming process. To fix this, I added Union to the end of all "union" types automatically. Since these types were already being renamed, it's clear that their actual type names are not important. Thus, I feel confident that this is okay.

Take a look, let me know what you think, though its a lot.

Hello, it seems that whenever I receive a webhook involving setup intents, async stripe fails to parse them. The endpoints where I receive this parsing error is:

• setup_intent.created
• setup_intent.succeeded

This is the error that is thrown.

BadParse("Error(\"unknown variant `setup_intent`, expected one of `account`, `application_fee`, `fee_refund`, `balance`, `bank_account`, `card`, `charge`, `customer`, `dispute`, `checkout.session`, `file`, `invoice`, `invoiceitem`, `order`, `order_return`, `payment_method`, `payment_intent`, `payout`, `plan`, `product`, `refund`, `review`, `sku`, `subscription`, `transfer`\", line: 9, column: 30)")

Currently running straight off of the github (I believe this commit):

async-stripe = { git = "https://github.com/arlyon/async-stripe", default-features = true, features = ["runtime-tokio-hyper-rustls"] }

✔️ @arlyon here! For a fix, please see this comment #154 (comment). This issue is now about determining the best way to fix the aliasing issue.

Hi! I just updated from rc3 to 0.13

I'm trying to create a subscription with SubscriptionPaymentBehavior::DefaultIncomplete

When I pass SubscriptionPaymentBehavior::DefaultIncomplete to CreateSubscription (wrapping inside Option appropriately), the compiler complains that I'm passing the wrong one:

expected enum stripe::resources::generated::billing::subscription::SubscriptionPaymentBehavior, found enum SubscriptionPaymentBehavior

I'm using stripe::SubscriptionPaymentBehavior

If I try using stripe::resources::generated::billing::subscription::SubscriptionPaymentBehavior, the compiler complains that resources is a private module

My features: async-stripe = { version = "0.13", features = ["runtime-tokio-hyper", "webhook-events"] }

Hi, I need the LoginLink API. Do you have any objection to me finishing that out and then getting it pulled in here upstream?

It's no secret that this library has quite terrible compile perf:

• high compile times
• very large binaries
• high degree of monomorphisation

I'm opening this as an issue, even though it's probably closer to the question "How do I make sense of the PaymentIntentOffSession enum?" Apologies if this raises unnecessary alarm.

I wish to use a CreatePaymentIntent object to create a payment intent. From the Stripe docs, the off_session field should be a boolean value; but the CreatePaymentIntent object expects a PaymentIntentOffSession enum. Where did this enum come from, and how should it be used when creating payment intents?

The CreatePaymentMethod doesn't have a card parameter. Since this is probably the most common usage of this, that's probably pretty bad. I'm looking into why this is happening as it is inconvenient for testing.

"url" field is missing from CheckoutSession, it is mandatory to have the URL created by stripe for the checkout session to redirect the customer to.

Some progress made here: wyyerd/stripe-rs@master...disconsented:feature/2020-08-27

It would be nice to have a github action that runs openapi-install every week or so and runs all the tests against it.

There are places in the codebase where unwrap is being used. To resolve this we will need a breaking change.

Hi, I'm trying to construct a WebhookEvent using the Webhook::construct_event method and I'm running into the following error:

BadParse(
    Error("missing field `object`", line: 78, column: 3),
)

I'm just wondering if anyone else has encountered the same issue.

The webhook payload is as follows:

{
  "id": "evt_3KdAWACEFgkItOVj0KRZcS1B",
  "object": "event",
  "api_version": "2020-08-27",
  "created": 1647251326,
  "data": {
    "object": {
      "id": "pi_3KdAWACEFgkItOVj0iSSHzFz",
      "object": "payment_intent",
      "amount": 2000,
      "amount_capturable": 0,
      "amount_received": 0,
      "application": null,
      "application_fee_amount": null,
      "automatic_payment_methods": null,
      "canceled_at": null,
      "cancellation_reason": null,
      "capture_method": "automatic",
      "charges": {
        "object": "list",
        "data": [
        ],
        "has_more": false,
        "total_count": 0,
        "url": "/v1/charges?payment_intent=pi_3KdAWACEFgkItOVj0iSSHzFz"
      },
      "client_secret": "pi_3KdAWACEFgkItOVj0iSSHzFz_secret_9PN3BQrvfH8sTbPiCwJeymaQY",
      "confirmation_method": "automatic",
      "created": 1647251326,
      "currency": "usd",
      "customer": null,
      "description": "(created by Stripe CLI)",
      "invoice": null,
      "last_payment_error": null,
      "livemode": false,
      "metadata": {
      },
      "next_action": null,
      "on_behalf_of": null,
      "payment_method": null,
      "payment_method_options": {
        "card": {
          "installments": null,
          "mandate_options": null,
          "network": null,
          "request_three_d_secure": "automatic"
        }
      },
      "payment_method_types": [
        "card"
      ],
      "processing": null,
      "receipt_email": null,
      "review": null,
      "setup_future_usage": null,
      "shipping": {
        "address": {
          "city": "San Francisco",
          "country": "US",
          "line1": "510 Townsend St",
          "line2": null,
          "postal_code": "94103",
          "state": "CA"
        },
        "carrier": null,
        "name": "Jenny Rosen",
        "phone": null,
        "tracking_number": null
      },
      "source": null,
      "statement_descriptor": null,
      "statement_descriptor_suffix": null,
      "status": "requires_payment_method",
      "transfer_data": null,
      "transfer_group": null
    }
  },
  "livemode": false,
  "pending_webhooks": 2,
  "request": {
    "id": "req_un0u2CY4R1RhOS",
    "idempotency_key": "8f10b1fb-fc24-4db1-81b7-204943f65222"
  },
  "type": "payment_intent.created"
}