The current java api provides no compile-time safety for api call parameters. Neither the names of the parameters nor the types being passed as values are checked at compile time. It would be beneficial to users of the API to have a fluent style api for Stripe api calls. For example:

    final Refund refund = 
        stripe.refund()
        .create(chargeId)
        .reverseTransfer(true)
        .metadata("reason", "refund due to cancellation")
        .idempotencyKey(stripeRefundNonce)
        .get();

This might seem like a lot of work, however the official Stripe API reference is structured so well that such an API can be generated directly from the HTML. In fact, I know it can be done because that's what I'm doing in my project. A little bit of Javascript, jQuery, and Mustache is all that's needed to create a fluent style api directly from the official reference documentation. Every time the API changes, the corresponding java code can be regenerated automatically. Additionally, because it comes directly from the documentation, we can also incorporate Javadoc:

    /**
     * A cursor for use in pagination. <code>ending_before</code> is an
     * object ID that defines your place in the list. For instance, if
     * you make a list request and receive 100 objects, starting with
     * <code>obj_bar</code>, your subsequent call can include
     * <code>ending_before=obj_bar</code> in order to fetch the previous
     * page of the list.
     */
    public final AllMethod endingBefore(final String endingBefore) {
        return set("ending_before", endingBefore);
    }

If this is something that should be in the official Stripe API then I can create a pull request for it, otherwise I can create a separate project that builds on top of stripe-java.

cc @stripe/api-libraries

This is a proposal to make use of Project Lombok and particularly its @Getter / @Setter and @EqualsAndHashCode annotations to reduce the amount of boilerplate code.

This PR removes about 6,000 lines of code, while adding some functionality as some of the classes currently lacks some setters or equals() / hashCode() methods.

This is obviously a non-trivial change, and I don't suggest it be merged as is, but I think it's an interesting improvement worth exploring.

The current interface for creating and updating records requires manual construction of HashMaps.

Map<String, Object> planParams = new HashMap<String, Object>();
planParams.put("amount", 5000);
planParams.put("interval", "month");
planParams.put("name", "Gold large");
planParams.put("currency", "usd");
planParams.put("id", "gold-large");
Plan.create(planParams);

This pull requests uses Google AutoValue to generate a typed interface for API requests. Creating a plan can now be down in a type-safe manner.

CreatePlan params = CreatePlan.builder()
    .amount(5000)
    .interval("month")
    .name("Gold large")
    .currency("usd")
    .id("gold-large")
    .build()
Plan.create(params);

Breaking changes

If you were calling a method with null before, you'll need to cast or pass an empty value object now.

-Account account = Account.create(null);
+Account account = Account.create(new HashMap<String, Object>());

TODO

• [x] Support nullable arguments
• [x] Update all methods to include a signature with the correct ValueObject

Future work

• Support nested input parameters
• Use annotations to instead of toMap
• Type safe interface for retrieval methods (all, retrieve, etc.)

I'm using this library in a multithreaded environment against various keys granted via oauth by Stripe users for my app, so I provide the appropriate key in request options for each call I make. However, it seems like some of the models' methods don't copy these credentials on additional requests that are made.

e.g., I call Invoice.list passing my request options, and then on each invoice I call getLines and use the autoPagingIterable to access all invoice line items. However, for any invoice with enough line items such that an additional request is needed I get an exception like this:

java.lang.RuntimeException: Unable to lazy-load stripe objects
Caused by: com.stripe.exception.AuthenticationException: No API key provided. (HINT: set your API key using 'Stripe.apiKey = <API-KEY>'. You can generate API keys from the Stripe web interface. See https://stripe.com/api for details or email [email protected] if you have questions.

e: I'm using 1.41.0

Describe the bug

When trying to debug EventDataObjectDeserializer public Optional getObject() I hit comment lines.

To Reproduce

1. Using Maven add dependency 20.128.0
2. Create a Java snippet: Event event = Webhook.constructEvent(json, header, endpointSecret); Optional optional = event.getDataObjectDeserializer().getObject();
3. Using Stripe CLI hit a webhook endpoint.
4. Step into getDataObjectDeserializer.

Expected behavior

I expect to step through getObject method code.

Code snippets

@RequestMapping(value = "/stripeCheckoutSessionCompleted", method = POST, consumes = APPLICATION_JSON_VALUE, produces = APPLICATION_JSON_VALUE)
    @ResponseBody
    public String stripeWebhookEndpoint(HttpServletRequest request) {
        String header = request.getHeader("Stripe-Signature");
        try {
            String json = IOUtils.toString(request.getInputStream(), StandardCharsets.UTF_8);
            Event event = Webhook.constructEvent(json, header, endpointSecret);
            Optional<StripeObject> optional = event.getDataObjectDeserializer().getObject();
...

OS

Windows 10

Java version

11

stripe-java version

20.128.0

API version

2020-08-27

Additional context

No response

It's important to be able to set a reasonable timeout for http connections. If production server has a network problem or Stripe serve is down, a reasonable timeout could prevent the calling thread from being blocked for huge amount of time.

Timeout values were previously hard coded in LiveStripeResponseGetter, and the values were frankly quite high (30 seconds for connection and 80 for reads).

Example:

RequestOptions options = RequestOptions.builder()
    .setConnectionTimeout(2000)
    .setReadTimeout(5000)
    .build()

Customer.create(params, options);

The Task

Implement balance transactions view with metadata (e.g. customer name, payment summary) rendered for records of type "charge". To make it clear, Charge objects we create are populated with metadata we need to store. This task is only about extracting that metadata from balance transaction records corresponding to charges.

Note: I'm aware balance transactions do not support metadata, but according to API docs, "source" object on balance transaction is expandable and is capable of returning full nested structure of corresponding charge, transfer, etc.

The Problem

If "data.source" expansion is requested, returned JSON data structure looks correct - it does contain nested objects.

However, stripe-java unfortunately does not support this currently.

Consider the following API call:

Map<String, Object> params = new HashMap<String, Object>(); params.put("expand", Arrays.asList(new String[]{ "data.source.metadata" })); BalanceTransactionCollection transactions = BalanceTransaction.list(params);

It worked perfectly without "expand" param set (but obviously didn't contain the nested objects we needed to get), but as long as param is set, it fails with the following exception:

com.google.gson.JsonSyntaxException: java.lang.IllegalStateException: Expected a string but was BEGIN_OBJECT at line 15 column 18 path $.data[0].source

This happens when execution flow reaches the following line within LiveStripeResponseGetter._request method:

T resource = APIResource.GSON.fromJson(rBody, clazz);

Obviously Gson fails to properly deserialize balance transaction JSON structure that has nested source object, b/c BalanceTransaction.source is defined as String.

To make it clear, I'm aware that stripe-java has support for expandable fields, but the challenge there is that just changing "source" type on BalanceTransaction from String to ExpandableField<...> wouldn't work b/c nested "source" objects within returned JSON might have different types (i.e. some are charges, others are transfers, adjustments, etc), while ExpandableField requires single generic type (<? extends HasId>).

The Solution

Note: I tried to solve this in a different way initially - see pull request https://github.com/stripe/stripe-java/pull/361 - , which worked just fine with JSON structures returned by end-point requests, but was incompatible with incoming JSON structures for webhooks (was throwing exception on APIResource.GSON.fromJson(jsonBody, Event.class) call); this new solution supports both and looks a bit more elegant too.

Here's a list of changes I made to solve the problem:

• added a bunch of transient properties for various possible nested "source" object types (e.g. “sourceCharge", “sourceTransfer", etc.) to BalanceTransaction class (I only added a few, might need to support more in the future) which would be populated based on the type of corresponding "source" object (others would remain null); so, for example, if nested "source" object was of type "charge", you'd be able to call balanceTransaction.getSourceCharge() to get populated Charge instance
• implemented new BalanceTransactionDeserializer class that supports nested "source" objects deserialization for balance transactions and registered it within APIResource.GSON (i.e. mapped it to BalanceTransaction class via GsonBuilder)

I only needed support for nested "charge" objects, but also added support for "transfer" and "refund" ones - for the sake of having an example of how to extend that logic to support more nested object types, if needed.

NOTE: I did these changes on separate branch - balance-transaction-deserializer - which is based on v3.11.0 of code-base b/c that's the version we use in production currently (i.e. version our code-base is currently integrated with); changes are pretty straightforward though and shouldn't be hard to merge into master branch (GitHub indicates there are no conflicts).

IMPORTANT: as far as I can tell, these are non-breaking changes that should be safe to merge in - they should not break any existing code that uses stripe-java, i.e. if someone calls balanceTransaction.getSource() in their code, they would still be getting String ID, while those who need full nested source object would rather call one of the new methods for the appropriate "source" object type, e.g. balanceTransaction.getSourceCharge() to get nested Charge object; BalanceTransactionDeserializer only handles nested "source" object for balance transaction if one is present and only handles types it knows how to handle - in all other cases it does nothing besides of setting "source" object ID (which it always does, of course), so it won't throw exceptions in case no/new/unknown "source" objects are present in JSON data returned by API end-points; and, finally, just FYI: BalanceTransactionTest still passes without issues (I did not do any changes to it).

My code :

 Invoice invoice = (Invoice) event.getDataObjectDeserializer().getObject();
 Customer customer = invoice.getCustomerObject();

NullPointerException at the first line & in the second line the customer object is null!

The same code was working fine 2 months ago, Stripe maven version : 8.0.2 API version: 2019-03-14.

Could you advise?

Thanks.

Hi there,

I juste tried to upgrade from Stripe 7 to Stripe 8 and found that HasSourceTypeData interface is removed. This mean that we cannot use getTypeData anymore. While it's a huge improvement, I am struggling with a side effect.

My sources are always either a card or a 3DSecured card. Since they both have the fields three_d_secure, brand, .... I was not performing any check on the type because it was simply useless.

By reviewing both Card and ThreeDSecureclasses, I found that they are the same with the only difference that ThreeDSecure class has three additional fields: authenticated, card, customer.

Would it be possible to extends ThreeDSecure from Card instead of StripeObject?

Thanks,

Fixes #308.

Changed accountBalance's attribute in the Customer class from Integer to Long to avoid overflow issues.

r? @brandur cc @stripe/api-libraries

Adds support for iteration over Stripe collections with lazy pagination that's activated as necessary.

Based on previous work by @hardtoe in #208. (Thanks for that!)

This pull is still a WIP. I'm going to take one more look at the interface and implement a basic test suite so that we have some better guarantees that everything works as we might expect.

Is your feature request related to a problem? Please describe.

Without the runtime hints, it's not possible to use the SDK in native images.

Describe the solution you'd like

To be able to use the SDK in native images without providing runtime hints (but the user).

Describe alternatives you've considered

The alternative in Spring is to generate the runtime hints during AoT. However the end user (of the SDK) is not the best person to write such hints. (For example, since I didn't know what to add, I added hints for full reflection of all classes in model and param packages. The JSON file is 1.1MB big and has more than 4K entries.)

Additional context

No response

Is your feature request related to a problem? Please describe.

When writing unit tests, there is a need to avoid outbound RPCs to another server. Today the Stripe API uses static methods and global (or request) config parameters, but there does not seem to be a way to mock the request/verify the request without running StripeMock, which is perhaps too large for a java unit test.

Describe the solution you'd like

If there was a constructor/factory based approach to constructing the stripe api, then we would be able to mock this away in our DI layer.

Today

Customer.create(customerCreateParamsObj);

Desirable alternatives

stripeFactoryObj.customerService().create(customerCreateParamsObj);

In my code I would likely provide CustomerService via DI, and then call like such:

customerService.create(customerCreateParamsObj);

This way I would be able to provide a Mockito implementation for CustomerService and setup mocks/verifications.

Describe alternatives you've considered

My solution until this is supported will be to wrap every Stripe API in a class/method and indirectly call the stripe API.

Alternatively it seems clients could use Mockito to mock static methods, though this approach is less desirable.

Additional context

No response

Is your feature request related to a problem? Please describe.

I am using Kotlin and the use of the builders provided on these classes is overly verbose.

Describe the solution you'd like

Make the constructors public, so I can build the objects myself, using Kotlin's Type Safe Builders.

Also, I believe the fields will need to be accessible.

Or even create a Kotlin extensions library with the type-safe builders included.

Describe alternatives you've considered

I've tried creating a wrapper around the builders themselves, but it turned out to be extremely cumbersome.

Additional context

For example, instead of:

val lineItem = SessionCreateParams.LineItem.builder()
            .setPrice(priceID)
            .setQuantity(1)
            .build()

SessionCreateParams.builder().apply {
            setMode(SUBSCRIPTION)
            addPaymentMethodType(SessionCreateParams.PaymentMethodType.CARD)
            addLineItem(lineItem)
            setSuccessUrl("$domainURL/stripe/checkout?sessionID={CHECKOUT_SESSION_ID}&success=true")
            setCancelUrl("$domainURL/stripe/checkout?success=false")
            setAllowPromotionCodes(true)
            setSubscriptionData(subscriptionData)

I could simply do

createSessionParams {
  mode = SUBSCRIPTION
  paymentMethodTypes += CARD
  lineItems = listOf(
    lineItem {
      price = priceID
      quantity = 1
    }
  )
  successUrl = "$domainURL/stripe/checkout?sessionID={CHECKOUT_SESSION_ID}&success=true"
  cancelUrl = "$domainURL/stripe/checkout?success=false"
  allowPromitionCodes = true
  subscriptionData = 
}

But I cannot instantiate the classes myself, as the constructors are private.

Describe the bug

handleApiError maps all 402 status code responses to CardException. We have received responses that in the Stripe dashboard are "type": "invalid_request_error", but result in a CardException. (The CardException has a null code which causes us problems.) An example of the Response body is shown further below.

I have been in touch with Stripe support who say "our error documentation doesn't map status codes to specific error types, so the invalid_request_error may not always go hand in hand with the 404 status code.". So I think handleApiError needs to allow for invalid_request_error type in the case 402: branch.

Example of Response body for invalid_request_error type which results in CardException:

Response body
{
  "error": {
    "message": "The payment is blocked because the used IBAN has been suspended. You can learn more about this at https://support.stripe.com/questions/sepa-debit-chargebacks-faq and if you need assistance processing a payment please contact us via https://support.stripe.com/contact/ for further information.",
    "type": "invalid_request_error"
  }
}

To Reproduce

Using the Charges API create a Charge with an underlying payment source where the associated IBAN has been disputed 3 times in row. Such that Stripe block the Charge and return an invalid_request_error response. See https://support.stripe.com/questions/sepa-debit-chargebacks-faq

Expected behavior

Expected the Stripe Java SDK to translate the invalid_request_error with HTTP status code 402 into an InvalidRequestException. Actual behavior: CardException where only the message property is populated, notably not the code.

Code snippets

No response

OS

macOS

Java version

Java 11

stripe-java version

20.121.0

API version

2020-08-27

Additional context

At https://support.stripe.com/questions/sepa-debit-chargebacks-faq Stripe note this is new behavior since 2022-03-07. This is exactly consistent with when we started seeing this issue.

Tracking issue for supporting other libraries for JSON (de)serialization.

We've had a number of requests over the years to do this, so will be using this as the main feature request to a) track support for this and b) track work in this space.

Is your feature request related to a problem? Please describe.

The EventData class which is defined in the Event object has a member object of type JsonObject which is a type defined by the com.google.gson library.

When I try to deserialize stored json into an Event object using a com.fasterxml.jackson ObjectMapper, errors are thrown because the object jsonString contains fields not explicitly defined by the JsonObject.

https://github.com/stripe/stripe-java/blob/master/src/main/java/com/stripe/model/EventData.java#L28

Describe the solution you'd like

The object field of the EventData class should be of type Map<String, Object> or something similar... and anywhere else in the models where JsonObject is used, it should be replaced with the same solution

Describe alternatives you've considered

No response

Additional context

No response