stripe / stripe-mock

stripe-mock is a mock HTTP server that responds like the real Stripe API. It can be used instead of Stripe's testmode to make test suites integrating with Stripe faster and less brittle.

stripe-mock

stripe-mock is a mock HTTP server based on the real Stripe API. It accepts the same requests and parameters that the Stripe API accepts, and rejects requests whose parameters are not recognized or have incorrect types. Its responses resemble the responses of the real Stripe API in terms of data type; however, stripe-mock does not attempt to reproduce the behavior of the real Stripe API at all. It cannot reject all invalid requests, and its responses are completely hardcoded. They will have a correct type, but they will not necessarily be realistic Stripe responses.

stripe-mock is meant for basic sanity checks. We use it in the test suites of our server-side SDKs, like stripe-ruby, stripe-go, etc, to help validate that the SDK hits the right URL and sends the right parameters. If you have more sophisticated testing needs, you shouldn't use stripe-mock. Always test changes to your Stripe integration against testmode. For regression test suites, you should define your own mocks, or use a playback testing tool such as the VCR gem.

While stripe-mock is naïve, it is powered by the Stripe OpenAPI specification and is therefore kept up-to-date with the latest methods, resources, and fields.

Features and limitations

stripe-mock supports the following features:

• It has a catalog of every API URL and their signatures. It responds to URLs that exist with a resource that it returns and 404s on URLs that don't exist.
• JSON Schema is used to check the validity of the parameters of incoming requests. Validation is comprehensive, but far from exhaustive, so don't expect the full barrage of checks of the live API.
• Responses are generated based off resource fixtures. They're also generated from within Stripe's API, and similar to the sample data available in Stripe's API reference. They are hardcoded, and will not necessarily represent realistic responses based on the parameters you input into the request.
• It reflects the values of valid input parameters into responses where the naming and type are the same. So if a charge is created with amount=123, a charge will be returned with "amount": 123.
• It will respond over HTTP or over HTTPS. HTTP/2 over HTTPS is available if the client supports it.

Limitations:

• stripe-mock is stateless. Data you send on a POST request will be validated, but it will be completely ignored beyond that. It will not be reflected on the response or on any future request -- unlike the real Stripe API, which stores the information you send it.
• For polymorphic endpoints (say one that returns either a card or a bank account), only a single resource type is ever returned. There's no way to specify which one that is.
• It's locked to the latest version of Stripe's API and doesn't support old versions.
• Testing for specific responses and errors is currently not supported. It will return a success response instead of the desired error response.

Future plans

The scope we envision for stripe-mock has significantly narrowed since 2017 when we first released it. Back in 2017, our vision was for stripe-mock was to return responses that were realistic as well as just having the expected types. This has changed. We are currently not planning to add statefulness or more sophisticated testing features to stripe-mock. stripe-mock will remain a tool for basic sanity checks. If you have more sophisticated needs, you should define your own mocks, use a playback testing tool like the VCR gem, or find a community library you trust. Be careful, though. Always test changes to your Stripe integration against testmode. Mock implementations of Stripe can never behave exactly at the Stripe API does, and might differ in nuanced (and potentially dangerous) ways.

Usage

If you have Go installed, you can install the basic binary with:

go install github.com/stripe/stripe-mock@latest

With no arguments, stripe-mock will listen with HTTP on its default port of 12111 and HTTPS on 12112:

stripe-mock

Ports can be specified explicitly with:

stripe-mock -http-port 12111 -https-port 12112

(Leave either -http-port or -https-port out to activate stripe-mock on only one protocol.)

Have stripe-mock select a port automatically by passing 0:

stripe-mock -http-port 0

It can also listen via Unix socket:

stripe-mock -http-unix /tmp/stripe-mock.sock -https-unix /tmp/stripe-mock-secure.sock

Homebrew

Get it from Homebrew or download it from the releases page:

brew install stripe/stripe-mock/stripe-mock

# start a stripe-mock service at login
brew services start stripe-mock

# upgrade if you already have it
brew upgrade stripe-mock

# restart the service after upgrading
brew services restart stripe-mock

The Homebrew service listens on port 12111 for HTTP and 12112 for HTTPS and HTTP/2.

Docker

docker run --rm -it -p 12111-12112:12111-12112 stripe/stripe-mock:latest

The default Docker ENTRYPOINT listens on port 12111 for HTTP and 12112 for HTTPS and HTTP/2.

Sample request

After you've started stripe-mock, you can try a sample request against it:

curl -i http://localhost:12111/v1/charges -H "Authorization: Bearer sk_test_123"

Development

Testing

Run the test suite:

go test ./...

Updating OpenAPI

Update the OpenAPI spec by running make update-openapi-spec in the root of the repo.

make update-openapi-spec

Dependencies

Dependencies are managed using go modules and require Go 1.11+ with GO111MODULE=on.

Release

Releases are automatically published by Travis CI using goreleaser when a new tag is pushed:

git pull origin --tags
git tag v0.1.1
git push origin --tags

stripe-mock's Issues

Applying test coupon to a customer is not reflected in response data

cus = stripe.Customer.retrieve('cus_foo')
cus.coupon = '25_5OFF'
cus = cus.save()

Expectation:

print cus.discount 

{
    "coupon": {
      "amount_off": null, 
      "created": 1234567890, 
      "currency": null, 
      "duration": "repeating", 
      "duration_in_months": 3, 
      "id": "25_5OFF", 
      "livemode": false, 
      "max_redemptions": null, 
      "metadata": {}, 
      "name": "25.5% off", 
      "object": "coupon", 
      "percent_off": 25.5, 
      "redeem_by": 1234567890, 
      "times_redeemed": 0, 
      "valid": true
    }
    "customer": "cus_foo", 
    "end": null, 
    "object": "discount", 
    "start": 1537584636, 
    "subscription": null
}

Current result:

print cus.discount

None

Reflect an object's primary ID from a path back in the response

#59 implemented this feature, but there are a few cases in which it doesn't work:

• non-CRUD methods:

  • POST /v1/accounts/<ID>/reject
  • POST /v1/application_fees/<ID>/refund
  • POST /v1/charges/<ID>/capture
  • POST /v1/charges/<ID>/refund
  • POST /v1/payouts/<ID>/cancel
  • POST /v1/sources/<ID>/verify

• nested resources:

  • POST /v1/application_fees/<FEE_ID>/refunds/<FEE_REFUND_ID>: this returns an application_fee with id=<FEE_REFUND_ID>, but the fee attribute is that of the fixture (fee_1CDJmvCLWM6HLS3K5kilrl2R) instead of <FEE_ID>

Use test card numbers and tokens in the mock

I was surprised that Stripe's own test tokens for invalid cards, etc aren't supported by this mock out of the box. I feel like supporting this should be a bit higher in the priority list than storing data locally:

https://stripe.com/docs/testing#cards

Adding external (bank) account to account using hash of values fails

It seems like the mock validation of the field external_account for this endpoint:
https://stripe.com/docs/api/external_account_bank_accounts/create?lang=curl

isn't aligned with the test/live API:

This curl calling the test API is successfully creating the external account object:

curl https://api.stripe.com/v1/accounts/{account_id}/external_accounts   -u sk_test_{hidden}:   -d 'external_account[object]=bank_account&external_account[account_number]=DE89370400440532013000&external_account[currency]=EUR&external_account[country]=DE'

But the same call against the mock fails using a map of values instead of a string token for extenral_account:

curl http://localhost:12111/v1/accounts/{account_id}/external_accounts   -u sk_test_{hidden}:   -d 'external_account[object]=bank_account&external_account[account_number]=DE89370400440532013000&external_account[currency]=EUR&external_account[country]=DE'

Response from mock:

'
{
  "error": {
    "message": "Request validation error: validator 0xc420e7ebd0 failed: object property 'external_account' validation failed: value is not a string (Kind: map)",
    "type": "invalid_request_error"
  }
}

'Create a card' responds with 'bank account' object instead of 'card object'

When I try to create a credit card using the following request:

curl http://localhost:12111/v1/customers/cus_BsLON0VirK4qBO/sources \ -u sk_test_123: \ -d source=tok_1B3xSU2eZvKYlo2Cj8aaqtGj

I get this:

{ "account": "acct_1032D82eZvKYlo2C", "account_holder_name": "Jane Austen", "account_holder_type": "individual", "bank_name": "STRIPE TEST BANK", "country": "US", "currency": "usd", "fingerprint": "1JWtPxqbdX5Gamtc", "id": "ba_1B3xSU2eZvKYlo2CDAgYCVfe", "last4": "6789", "metadata": {}, "object": "bank_account", "routing_number": "110000000", "status": "new" }

Even when I try with /cards. I don't know which one is correct because in stripe-go it is /cards but in the stripe api docs it is /sources.

GET requests should not require a `Content-Type` header

With the latest version, sending a GET request without a Content-Type header fails:

❯ curl -v http://localhost:12111/v1/customers/cus_123 -H "Authorization: Bearer sk_test_123"
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 12111 (#0)
> GET /v1/customers/cus_123 HTTP/1.1
> Host: localhost:12111
> User-Agent: curl/7.54.0
> Accept: */*
> Authorization: Bearer sk_test_123
>
< HTTP/1.1 400 Bad Request
< Request-Id: req_123
< Stripe-Mock-Version: 0.29.0
< Date: Wed, 29 Aug 2018 10:30:11 GMT
< Content-Length: 165
< Content-Type: text/plain; charset=utf-8
<
{
  "error": {
    "message": "Request's `Content-Type` header was empty. Expected: `application/x-www-form-urlencoded`.",
    "type": "invalid_request_error"
  }
}
* Connection #0 to host localhost left intact

The Java client library does not include a Content-Type header when sending GET requests, so the test suite fails with the latest version of stripe-mock.

List endpoints should support `limit` parameter

When you use one of the List APIs and pass limit, the parameter is ignored and the returned list only contains one object. It would be great if it supported returning more than 1.

Best way to load fixtures via docker-compose.

What's the preferred way of loading custom fixtures via docker-compose?

My api is tightly coupled with specific skus and testing makes it rough with this, so I'd like to be able to define custom fixtures.

Thanks!

Panic when running with custom fixtures specified

$ stripe-mock -version
0.2.0

When I run stripe-mock with -fixtures ~/fixtures3.yaml -spec ~/spec3.yaml the server starts. The fixtures3.yaml and spec3.yaml are from https://raw.githubusercontent.com/stripe/openapi/5f2f0e245c07c918cca185902aceffc64a0b1957/openapi/fixtures3.yaml and https://raw.githubusercontent.com/stripe/openapi/5f2f0e245c07c918cca185902aceffc64a0b1957/openapi/spec3.yaml

But when I do

## Request (3)
curl -X "POST" "http://localhost:12111/v1/sources" \
     -H "Authorization: Bearer sk_test_123" \
     -H "Content-Type: application/x-www-form-urlencoded; charset=utf-8" \
     --data-urlencode "type=bitcoin"

the server crashes

stripe-mock -fixtures ~/fixtures3.yaml -spec ~/spec3.yaml
Routing to 107 path(s) and 186 endpoint(s) with 104 validator(s)
Listening on port 12111
Request: POST /v1/sources
2017/10/03 10:08:13 http: panic serving 127.0.0.1:51820: Responding to /v1/sources:
Dereferencing '#/components/schemas/source':
Using fixture 'source':
Schema is an object:
{
  "properties": {
    "amount": {
      "nullable": true,
      "type": "integer"
    },
    "client_secret": {
      "type": "string"
    },
    "code_verification": {
      "$ref": "#/components/schemas/source_code_verification_flow"
    },
    "created": {
      "type": "integer"
    },
    "currency": {
      "nullable": true,
      "type": "string"
    },
    "flow": {
      "type": "string"
    },
    "id": {
      "type": "string"
    },
    "livemode": {
      "type": "boolean"
    },
    "metadata": {
      "nullable": true,
      "type": "object"
    },
    "object": {
      "type": "string"
    },
    "owner": {
      "anyOf": [
        {
          "$ref": "#/components/schemas/source_owner"
        }
      ],
      "nullable": true
    },
    "receiver": {
      "$ref": "#/components/schemas/source_receiver_flow"
    },
    "redirect": {
      "$ref": "#/components/schemas/source_redirect_flow"
    },
    "statement_descriptor": {
      "nullable": true,
      "type": "string"
    },
    "status": {
      "type": "string"
    },
    "type": {
      "type": "string"
    },
    "usage": {
      "nullable": true,
      "type": "string"
    }
  },
  "required": [
    "client_secret",
    "created",
    "flow",
    "id",
    "livemode",
    "object",
    "status",
    "type"
  ],
  "type": "object",
  "x-expandableFields": [
    "code_verification",
    "owner",
    "receiver",
    "redirect"
  ],
  "x-resourceId": "source"
}
But example is:
map[owner:map[verified_email:<nil> verified_name:<nil> verified_phone:<nil> address:<nil> email:[email protected] name:<nil> phone:<nil> verified_address:<nil>] redirect:map[url: return_url: status:] statement_descriptor: usage:single_use code_verification:map[attempts_remaining:%!s(int=0) status:] id:src_1B3xSU2eZvKYlo2CYdL110Ll object:source type:bitcoin client_secret:src_client_secret_BQp65YD6eXk9NLfGKOwigCoK created:%!s(int=1234567890) flow:receiver amount:%!s(int=1000) receiver:map[address:test_1MBhWS3uv4ynCfQXF3xQjJkzFPukr4K56N amount_charged:%!s(int=0) amount_received:%!s(int=0) amount_returned:%!s(int=0) refund_attributes_method:email refund_attributes_status:missing] status:pending currency:usd livemode:%!s(bool=false) metadata:map[]]
goroutine 20 [running]:
net/http.(*conn).serve.func1(0xc420dce8c0)
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:1697 +0xd0
panic(0x134df00, 0xc420900960)
	/usr/local/Cellar/go/1.9/libexec/src/runtime/panic.go:491 +0x283
main.(*DataGenerator).generateInternal(0xc42087fb00, 0xc420ae4780, 0xc42027c365, 0xb, 0x0, 0xc420900160, 0xc420076660, 0x60, 0xc420a69860, 0xc420a69930, ...)
	/Users/brandur/Documents/go/src/github.com/stripe/stripe-mock/generator.go:151 +0x16af
main.(*DataGenerator).Generate(0xc42087fb00, 0xc420ae4780, 0xc42027c365, 0xb, 0x0, 0x1, 0x0, 0x0, 0x0)
	/Users/brandur/Documents/go/src/github.com/stripe/stripe-mock/generator.go:22 +0x120
main.(*StubServer).HandleRequest(0xc420b5d9c0, 0x159b240, 0xc4208fc540, 0xc4203e2000)
	/Users/brandur/Documents/go/src/github.com/stripe/stripe-mock/server.go:175 +0x55b
main.(*StubServer).HandleRequest-fm(0x159b240, 0xc4208fc540, 0xc4203e2000)
	/Users/brandur/Documents/go/src/github.com/stripe/stripe-mock/main.go:75 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4208f9f50, 0x159b240, 0xc4208fc540, 0xc4203e2000)
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:1918 +0x44
net/http.(*ServeMux).ServeHTTP(0x15e7c60, 0x159b240, 0xc4208fc540, 0xc4203e2000)
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:2254 +0x130
net/http.serverHandler.ServeHTTP(0xc42046fd40, 0x159b240, 0xc4208fc540, 0xc4203e2000)
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:2619 +0xb4
net/http.(*conn).serve(0xc420dce8c0, 0x159b8c0, 0xc42084a980)
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:1801 +0x71d
created by net/http.(*Server).Serve
	/usr/local/Cellar/go/1.9/libexec/src/net/http/server.go:2720 +0x288

I didn't make any changes to the files, so I'm not sure what is going on.

When I remove the -fixture path.yaml and only run it with -spec path.yaml it works fine.

Any idea?

Cannot update subscription with plan

The mock server responds with a 400 if a plan is included in the request body.

Tested with the following bash script:

update_sub

#!/bin/sh

key='sk_test_123';
sub='a_sub_in_test_mode';
plan='a_plan_in_test_mode;

url='https://api.stripe.com'

if [ "$1" = "mock" ]; then
  url='http://localhost:12111'
fi

curl $url/v1/subscriptions/$sub \
  -u "$key:" \
  -d plan=$plan

Running ./update_sub results in successful response from the stripe test server.
Running ./update_sub mock results in:

{
  "error": {
    "message": "Request validation error: validator 0xc000efbd10 failed: additional properties are not allowed: plan",
    "type": "invalid_request_error"
  }
}

Linux install not working based on README

I followed the directions with installing go then running go get -u github.com/stripe/stripe-mock. However, after closing my terminal and trying to restart my computer as well, stripe-mock wasn't a thing?

Any helpful debugging techniques anybody can think of?

Wrong Return Object for Bank Account Tokens API

The following request

curl https://api.stripe.com/v1/tokens \
   -u sk_test_XXXXXXXXXXXXX: \
   -d bank_account[country]=US \
   -d bank_account[currency]=usd \
   -d bank_account[account_holder_name]="Jenny Rosen" \
   -d bank_account[account_holder_type]=individual \
   -d bank_account[routing_number]=110000000 \
   -d bank_account[account_number]=000123456789

Returns back a card object when it should be a bank_account one

Fixture for /customer/:customer_id/sources endpoint

Which resource should I be editing in order to modify the returned response from /customer/:customer_id/sources?

Not sure if this is specific to stripe-go, but I'm trying to annotate the paymentsource with a source object, and I can't seem to figure out how to do so.

BalanceTransaction doesn't return application fee

As the title says I'm getting no application_fee in my returned balance transaction when using

        stripe_charge = Stripe::Charge.create({
          source: token.id,
          amount: stripe_amount,
          currency: from.currency,
          application_fee: application_fee,
          expand: ['balance_transaction']
        }.reverse_merge(opts), stripe_account: stripe_account)

New source of type 'three_d_secure' returns a validation error

When I create a new source of type "three_d_secure" an error is returned related to the card sent in the TypeData field.

Logs

Request: POST /v1/sources
Request data = map[metadata:map[booking_id:12345] amount:100 currency:eur owner:map[name:string] redirect:map[return_url:https://some-url.com] type:three_d_secure three_d_secure:map[card:card_1B3xSU2eZvKYlo2CB4hHWxFm]]
Request validation error: validator 0xc420a8cf90 failed: additional properties are not allowed: three_d_secure

License

Hi,

I consider borrowing stripe-mock hack for yaml parsing (mapstr.go) for open source project but unfortunately stripe-mock does not have any license. I want to make sure it's OK and follows your intentions. Could you please consider adding a license?

Publish docker image to docker hub?

Is there an official build of the docker image that can be used without building? I couldn't find one on docker hub.

Return properly formatted JSON response for errors

At the moment, stripe-mock returns a string instead of a valid JSON payload when an invalid Authorization header is sent. Similar issues happen when you have an invalid URL such as /v1/test.

What the API does today

curl https://api.stripe.com/v1/customers
{
  "error": {
    "type": "invalid_request_error",
    "message": "You did not provide an API key. You need to provide your API key in the Authorization header, using Bearer auth (e.g. 'Authorization: Bearer YOUR_SECRET_KEY'). See https://stripe.com/docs/api#authentication for details, or we can help at https://support.stripe.com/."
  }
}

curl https://api.stripe.com/v1/test \
>    -u sk_test_BQokikJOvBiI2HlWgH4olfQ2:
{
  "error": {
    "type": "invalid_request_error",
    "message": "Unrecognized request URL (GET: /v1/test). Please see https://stripe.com/docs or we can help at https://support.stripe.com/."
  }
}

What stripe-mock does today:

curl http://localhost:12111/v1/customers
"Please authenticate by specifying an `Authorization` header with any valid looking testmode secret API key. For example, `Authorization: Bearer sk_test_123`. Authorization was ''."

curl http://localhost:12111/v1/test \
>    -u sk_test_123:
"Not Found"

The issue lives in server.go around here though I haven't found which part causes this yet.

Destination Object For Charge Has Invalid Validator

The validator does not account for the endpoint of
https://stripe.com/docs/connect/destination-charges

// Set your secret key: remember to change this to your live secret key in production
// See your keys here: https://dashboard.stripe.com/account/apikeys
var stripe = require("stripe")("sk_test_XXXXXXXXXXXXXXXXX");

stripe.charges.create({
  amount: 1000,
  currency: "usd",
  source: "tok_visa",
  destination: {
            account: "{CONNECTED_STRIPE_ACCOUNT_ID}",
          },
}).then(function(charge) {
  // asynchronously called
});

It returns

Request: POST /v1/charges
Request data = map[amount:100 currency:usd source:tok_123456436 destination:map[account:ba_XXXXXXXXXXXX amount:68] metadata:map[merchantName:John Smith amountFromUs:100]]
Request validation error: validator 0xc4206904e0 failed: object property 'destination' validation failed: could not validateagainst any of the constraints
Response: elapsed=303.893µs status=400

stripe-mock doesn't work under Go Modules

When I try to install stripe-mock under go modules, I get a type error. I suspect this is related to the JSON Schema dependencies moving from github.com/lestrrat to github.com/lestrrat-go.

See if you can reproduce:

% GO111MODULE=on go install github.com/stripe/stripe-mock
go: finding github.com/lestrrat/go-jsschema latest
go: finding github.com/lestrrat/go-jsval latest
go: finding github.com/lestrrat/go-jsval/builder latest
go: finding github.com/lestrrat-go/pdebug latest
go: finding github.com/lestrrat-go/jsval latest
go: finding github.com/lestrrat-go/jsref/provider latest
go: finding github.com/lestrrat-go/jsref latest
go: finding github.com/lestrrat-go/jsschema latest
go: finding github.com/lestrrat-go/structinfo latest
go: finding github.com/lestrrat-go/jspointer latest
# github.com/stripe/stripe-mock/spec
../../pkg/mod/github.com/stripe/[email protected]/spec/validate.go:31:49: cannot use jsonSchema (type *"github.com/lestrrat/go-jsschema".Schema) as type *"github.com/lestrrat-go/jsschema".Schema in argument to validatorBuilder.BuildWithCtx
../../pkg/mod/github.com/stripe/[email protected]/spec/validate.go:36:2: cannot use validator (type *"github.com/lestrrat-go/jsval".JSVal) as type *"github.com/lestrrat/go-jsval".JSVal in return argument

Empty response when expanding an optional unset attribute

If you try to expand outcome.rule on a charge object, you get an empty response:

$ curl -vvvv -g "http://localhost:12111/v1/charges/ch_123?expand[]=outcome.rule" -u sk_test_123:
*   Trying ::1...
* TCP_NODELAY set
* Connected to localhost (::1) port 12111 (#0)
* Server auth using Basic with user 'sk_test_123'
> GET /v1/charges/ch_123?expand[]=outcome.rule HTTP/1.1
> Host: localhost:12111
> Authorization: Basic c2tfdGVzdF8xMjM6
> User-Agent: curl/7.54.0
> Accept: */*
>
* Empty reply from server
* Connection #0 to host localhost left intact
curl: (52) Empty reply from server

outcome.rule is a valid expandable attribute (cf. API ref), however it is only set when applicable and is not set in the fixtures file.

The API's behavior in this case is simply to return the charge object, e.g.:

$ curl -g "https://api.stripe.com/v1/charges/ch_...?expand[]=outcome.rule" -u $STRIPE_SECRET_KEY:
{
  "id": "ch_...",
  "object": "charge",
  ...
  "outcome": {
    "network_status": "declined_by_network",
    "reason": "expired_card",
    "risk_level": "normal",
    "seller_message": "The bank returned the decline code `expired_card`.",
    "type": "issuer_declined"
  },
  ...
}

Using as a library

Are there any plans to make it possible to use this as a library in a Go project? Would be fantastic to be able to launch the HTTP server in tests.

Only had a quick look through the code, but it seemed like exporting the StubServer fields might even be enough to achieve this?

Metadata doesn't work?

Seems creating resources with metadata doesn't (or at least every one I've tried).

See these logs for instance:

Request: POST /v1/subscription_items
Response schema: {
  "$ref": "#/components/schemas/subscription_item"
}
Request data: metadata%5BclusterId%5D=xx2&metadata%5BaccountId%5D=test-account&plan=ruby-express-932&subscription=sub_XXX
Expansions: []
Response data: {
  "created": 1505872622,
  "id": "si_YYY",
  "metadata": {},
  "object": "subscription_item",
  "plan": {
    "amount": 999,
    "created": 1505549157,
    "currency": "usd",
    "id": "ruby-express-932",
    "interval": "month",
    "interval_count": 1,
    "livemode": false,
    "metadata": {},
    "name": "Ruby Express",
    "object": "plan",
    "statement_descriptor": null
  },
  "quantity": 1
}
Response: elapsed=142.324µs status=200

SetupIntent missing client_secret

I wasn't entirely sure if this issue belongs here or the OpenAPI repo but the response for a SetupIntent returns null for the client_secret.

This being null causes issues when trying to test at the user level when used in conjunction with react-stripe-elements because of https://github.com/stripe/react-stripe-elements/blob/3fb4e57ec439f652857cbfd21597f00a2c7af5a7/src/co...

Customer#default_source not present in response

Hi,

I'm having this issue testing in Ruby, using stripe-mock, in which stripe_customer.default_source raises a NoMethodError. I'm afraid this is because responses from stripe-mock don't include this attribute.

Create a subscription with `off_session` params

With the new European legislation, we need to use setup_intent with usage=off_session to create a payment_method.
But if you don't put the params off_session=true when you create the subscription, the first payment stays in status incomplete.
With the real Stripe api, you can use this params but with Stripe-mock we can't 🙁, the lib returns this error

Request validation error: validator 0xc000813530 failed: additional properties are not allowed: off_session

Error creating a source

When I create a source, the following error occurs. I'm using the Docker image (latest tag, last updated 16 hours ago). The request body can be found in the trace.

Request: POST /v1/sources
Request data = map[owner:map[phone:[phone] address:map[line1:911 Everardo Loaf Suite 890 postal_code:03302 country:CO] email:[email protected] name:Rocio Schneider] token:tok_visa_debit type:card]
2018/05/28 10:27:56 http: panic serving 172.18.0.2:47992: reflect: call of reflect.Value.Type on zero Value
goroutine 2267 [running]:
net/http.(*conn).serve.func1(0xc4207960a0)
	/usr/local/go/src/net/http/server.go:1697 +0xd0
panic(0x7665c0, 0xc4201822c0)
	/usr/local/go/src/runtime/panic.go:491 +0x283
reflect.Value.Type(0x0, 0x0, 0x0, 0x0, 0x0)
	/usr/local/go/src/reflect/value.go:1694 +0x1a3
github.com/stripe/stripe-mock/generator/datareplacer.isSameType(0x74ce40, 0xc42015c250, 0x0, 0x0, 0xc420879aa8)
	/go/src/github.com/stripe/stripe-mock/generator/datareplacer/datareplacer.go:49 +0xa9
github.com/stripe/stripe-mock/generator/datareplacer.ReplaceData(0xc420822210, 0xc420822a20, 0xc42065c3d8)
	/go/src/github.com/stripe/stripe-mock/generator/datareplacer/datareplacer.go:38 +0x147
github.com/stripe/stripe-mock/generator/datareplacer.ReplaceData(0xc4208221b0, 0xc420822990, 0x76b120)
	/go/src/github.com/stripe/stripe-mock/generator/datareplacer/datareplacer.go:25 +0x1d4
main.(*DataGenerator).Generate(0xc420a3fb18, 0xc420a3fc28, 0x0, 0x0, 0x0, 0x1)
	/go/src/github.com/stripe/stripe-mock/generator.go:122 +0x208
main.(*StubServer).HandleRequest(0xc42055af40, 0x993e40, 0xc4201f6000, 0xc420168000)
	/go/src/github.com/stripe/stripe-mock/server.go:201 +0x6ce
main.(*StubServer).HandleRequest-fm(0x993e40, 0xc4201f6000, 0xc420168000)
	/go/src/github.com/stripe/stripe-mock/main.go:75 +0x48
net/http.HandlerFunc.ServeHTTP(0xc4201a0ef0, 0x993e40, 0xc4201f6000, 0xc420168000)
	/usr/local/go/src/net/http/server.go:1918 +0x44
net/http.(*ServeMux).ServeHTTP(0x9e3fe0, 0x993e40, 0xc4201f6000, 0xc420168000)
	/usr/local/go/src/net/http/server.go:2254 +0x130
net/http.serverHandler.ServeHTTP(0xc420930d00, 0x993e40, 0xc4201f6000, 0xc420168000)
	/usr/local/go/src/net/http/server.go:2619 +0xb4
net/http.(*conn).serve(0xc4207960a0, 0x9944c0, 0xc42067ab80)
	/usr/local/go/src/net/http/server.go:1801 +0x71d
created by net/http.(*Server).Serve
	/usr/local/go/src/net/http/server.go:2720 +0x288

By the way, I think it would be a good idea to tag releases in Docker Hub.

Creating plan doesn't return a product object

Running the following Java against the mock results in a NPE as the response doesn't include the Product object in the json.

Plan stripePlan = Plan.create(planParams);

log.info("Plan created successfully. planId: {} Plan name: {} ", stripePlan.getId(), stripePlan.getProductObject().getName());

JSON:

{
    "active":true,
    "aggregate_usage":null,
    "amount":2000,
    "billing_scheme":"per_unit",
    "created":1234567890,
    "currency":"gbp",
    "id":"900",
    "interval":"month",
    "interval_count":1,
    "livemode":false,
    "metadata":{

    },
    "nickname":null,
    "object":"plan",
    "product":"sampleplan",
    "tiers":null,
    "tiers_mode":null,
    "transform_usage":null,
    "trial_period_days":null,
    "usage_type":"licensed"
}

Deployment (Heroku button)

Hi,
this is a suggestion but it would be great to be able to deploy an instance through the click of a button

https://devcenter.heroku.com/articles/heroku-button

Thanks.

Invoicing Support?

One of the toughest things for us to test currently is invoicing. Primarily because most invoicing processes are initiated by Stripe. It would be very helpful to, at the very least, make a call to the mock requesting that it call an endpoint to initiate an invoicing event (e.g. invoice_created).

Customer and Subscription POST now return a `data` array in the JSON, which can't be de-serializaed to proper objects

We updated to latest stripe-mock/stripe-dontnet releases (0.60/27.10). Now both Customer and Subscription POST responses return an array of objects (the data field), whereas they used to return the newly added object. This appears not to be coherent with Stripe API, which still returns the object, and not an array. A quick check at the OpenAPI specification seems to confirm that a single object is still expected.

This is the StripeResponse.Content content following a Stripe.CustomerService.Create() call. The Stripe.Customer instance returned by this call is a non-initialized object (e.g. Customer.Id is null, like all other fields.)

"{\"data\":[{\"account_balance\":0,\"address\":null,\"balance\":0,\"created\":1234567890,\"currency\":\"usd\",\"default_source\":null,\"delinquent\":false,\"description\":null,\"discount\":null,\"email\":null,\"id\":\"cus_FJaYLWmiE8rxFC\",\"invoice_prefix\":\"180BC08\",\"invoice_settings\":{\"custom_fields\":null,\"default_payment_method\":null,\"footer\":null},\"livemode\":false,\"metadata\":{},\"name\":null,\"object\":\"customer\",\"phone\":null,\"preferred_locales\":[],\"shipping\":null,\"sources\":{\"data\":[{\"created\":1234567890,\"customer\":null,\"fingerprint\":\"OUv5A7ge4czHxnfR\",\"id\":\"aliacc_1EphH5IUzFSXAEcAfYCgLj9h\",\"livemode\":false,\"metadata\":{},\"object\":\"alipay_account\",\"payment_amount\":1000,\"payment_currency\":\"usd\",\"reusable\":false,\"used\":false,\"username\":\"[email protected]\"}],\"has_more\":false,\"object\":\"list\",\"url\":\"/v1/customers/cus_FJaYLWmiE8rxFC/sources\"},\"subscriptions\":{\"data\":[{\"application_fee_percent\":null,\"billing\":\"charge_automatically\",\"billing_cycle_anchor\":1234567890,\"billing_thresholds\":null,\"cancel_at_period_end\":false,\"canceled_at\":1234567890,\"collection_method\":\"charge_automatically\",\"created\":1234567890,\"current_period_end\":1234567890,\"current_period_start\":1234567890,\"customer\":\"cus_FJaYLWmiE8rxFC\",\"days_until_due\":null,\"default_payment_method\":null,\"default_source\":null,\"default_tax_rates\":[],\"discount\":null,\"ended_at\":1234567890,\"id\":\"sub_FKLz5hl0zyaPGd\",\"items\":{\"data\":[{\"billing_thresholds\":null,\"created\":1561579163,\"id\":\"si_FKLzxZRXl8f8qr\",\"metadata\":{},\"object\":\"subscription_item\",\"plan\":{\"active\":true,\"aggregate_usage\":null,\"amount\":2000,\"billing_scheme\":\"per_unit\",\"created\":1561402737,\"currency\":\"usd\",\"id\":\"gold\",\"interval\":\"month\",\"interval_count\":1,\"livemode\":false,\"metadata\":{},\"nickname\":null,\"object\":\"plan\",\"product\":\"prod_FJaYU37yVcOAWH\",\"tiers\":null,\"tiers_mode\":null,\"transform_usage\":null,\"trial_period_days\":null,\"usage_type\":\"licensed\"},\"quantity\":1,\"subscription\":\"sub_FKLzukkMx7NSmO\"}],\"has_more\":false,\"object\":\"list\",\"url\":\"/v1/subscription_items?subscription=sub_FKLz5hl0zyaPGd\"},\"latest_invoice\":null,\"livemode\":false,\"metadata\":{},\"object\":\"subscription\",\"plan\":{\"active\":true,\"aggregate_usage\":null,\"amount\":2000,\"billing_scheme\":\"per_unit\",\"created\":1561402737,\"currency\":\"usd\",\"id\":\"gold\",\"interval\":\"month\",\"interval_count\":1,\"livemode\":false,\"metadata\":{},\"nickname\":null,\"object\":\"plan\",\"product\":\"prod_FJaYU37yVcOAWH\",\"tiers\":null,\"tiers_mode\":null,\"transform_usage\":null,\"trial_period_days\":null,\"usage_type\":\"licensed\"},\"quantity\":1,\"start\":1234567890,\"start_date\":1234567890,\"status\":\"active\",\"tax_percent\":null,\"trial_end\":1234567890,\"trial_start\":1234567890}],\"has_more\":false,\"object\":\"list\",\"url\":\"/v1/customers/cus_FJaYLWmiE8rxFC/subscriptions\"},\"tax_exempt\":\"none\",\"tax_ids\":{\"data\":[{\"country\":\"DE\",\"created\":1234567890,\"customer\":\"cus_FJaYLWmiE8rxFC\",\"id\":\"txi_123456789\",\"livemode\":false,\"object\":\"tax_id\",\"type\":\"eu_vat\",\"value\":\"DE123456789\",\"verification\":{\"status\":\"pending\",\"verified_address\":null,\"verified_name\":null}}],\"has_more\":false,\"object\":\"list\",\"url\":\"/v1/customers/cus_FJaYLWmiE8rxFC/tax_ids\"},\"tax_info\":null,\"tax_info_verification\":null}],\"has_more\":false,\"object\":\"list\",\"url\":\"/v1/customers\"}"

Not sure if this is the intended behaviour, and then I am obviously missing something in my upgrade path.

Docker image can't be built

Hi!

I use stripe-mock as a docker-compose service for my tests as following:

  stripe-mock:
    build: "https://github.com/stripe/stripe-mock.git"

But since today when I try to build that image I receive this error:

Building stripe-mock
ERROR: error initializing submodules: Submodule 'openapi' (https://github.com/stripe/openapi) registered for path 'openapi'
Cloning into '/var/lib/docker/tmp/docker-build-git091063957/openapi'...
error: Server does not allow request for unadvertised object 35afa88433cd6991ab88847f33f0bbee03a97185
Fetched in submodule path 'openapi', but it did not contain 35afa88433cd6991ab88847f33f0bbee03a97185. Direct fetching of that commit failed.
: exit status 1

Validate incoming media type

It'd be a nice addition to make sure that a request's incoming Content-Type is the same as the media type dictated by OpenAPI spec. Mostly this won't make a difference because we'll probably fall back to form encoding, but it'd be useful for vetting implementations against the file endpoints.

Using request data in mock response

Hello, it would be great that the mock server uses the request data in its mock response, see code below:

card_information = { 'number': '4242424242424242', 'exp_month': 12, 'exp_year': year, 'cvc': '123' }
token = stripe.Token.create(card = card_information)
charge = stripe.charge.create(amount = 15340, currency = 'eur', source = token.id)
assert(charge['amount'] == 15340)   # FAILS because the returned amount is actually 100

This behaviour makes stripe-mock pretty useless for testing anything else than request formatting, and given the stripe-python library works great we don't need to test it :)

I understand that actually mocking the entire Stripe backend in stripe-mock would be way too much work (and also leak intellectual property ...), but maybe that could be considered on the few critical paths such as this one?

What I'm doing for now is creating my own Stripe mocked server, only implementing what I want to test, to avoid the test suite taking minutes.

Cheers,
Louis

Endpoint for file uploads?

Is there supposed to be an endpoint for file uploads?

Thanks!

New Account DelayDays Validation Error

When using PayoutSchedule DelayDaysMinimum parameter I get the following error:

params.PayoutSchedule.Interval = stripe.String("daily")
params.PayoutSchedule.DelayDays = stripe.Int64(0)
params.PayoutSchedule.DelayDaysMinimum = stripe.Bool(true)

Request: POST /v1/accounts
Request data = map[external_account:tok_1DoUTXYZ legal_entity:map[type:individual address:map[state:PA city:Pandatown country:US line1:123 Panda Lane line2:Apt 5 postal_code:76543] dob:map[day:1 month:1 year:1980] first_name:John last_name:Doe personal_id_number:000000000 ssn_last_4:0000] payout_schedule:map[delay_days:minimum interval:daily] support_email:[email protected] tos_acceptance:map[date:1547240600 ip:127.0.0.1 user_agent:Go-http-client/1.1] expand:[legal_entity.verification] debit_negative_balances:true email:[email protected] type:custom country:US support_phone:[phone]]

Request validation error: validator 0xc000999650 failed: object property 'payout_schedule' validation failed: object property 'delay_days' validation failed: value is not numeric
Response: elapsed=392.876µs status=400

Deleted resources have an empty `id` string

When replying to resource deletion requests, stripe-mock returns an empty string for the id attribute:

$ curl -X DELETE http://localhost:12111/v1/customers/cus_123 -H "Authorization: Bearer sk_test_123"
{
  "deleted": true,
  "id": ""
}

The live API sends back the ID of the deleted resource:

$ curl -X DELETE https://api.stripe.com/v1/customers/cus_... -u $STRIPE_SECRET_KEY:
{
  "id": "cus_...",
  "deleted": true
}

Maintain a cache of idempotency keys and check for reuse

It would be nice if stripe-mock maintained a set of recently used idempotency keys to detect when a client tries to reuse a key with different parameters. In those cases we could reject the request just like the real Stripe API would do. (Keys would be evicted from the cache after some period of time so that it doesn't grow in an unbounded way.)

This would have caught the problem in stripe/stripe-ruby#598.

Allow API Key to use restricted key

Currently stripe-mock returns an error when using a restricted key (rk_) vs using the standard secret key (sk_). A very simple change would resolve this and allow for a developer to use either. It is much more common (on my project anyway) for developers to be issued restricted keys so this would greatly improve the dev workflow.

Below is the code change needed (I tried to submit a PR but was unable):
server.go file - line 781-83
Current structure:
if keyParts[0] != "sk" { return false }
Updated fix:
if keyParts[0] != "sk" || keyParts[0] != "rk" { return false }

returned `id`s are the same for every request

Since the returned ids are just taken from a fixture, the same id is returned every time. This causes integrity errors when testing the system I am working with

url-encoded id in path causes 404

Coming from stripe/stripe-java#737

It seems like stripe-mock has different behavior from our actual backend behavior. Although id is properly url-encoded, stripe-mock still rejects it.

@ob-stripe suggests a root-problem here stripe/stripe-java#737 (comment)

To reproduce the problem:

For a string ID: Pro plan $699/month with url-encoded form Pro+plan+%24699%2Fmonth.

curl -i http://localhost:12111/v1/plans/Pro+plan+%24699%2Fmonth -H "Authorization: Bearer sk_test_123"

Stripe mock will give error: 404 with

{
  "error": {
    "message": "Unrecognized request URL (GET: /v1/plans/Pro+plan+$699/month).",
    "type": "invalid_request_error"
  }
}

But on test endpoint shows that our backend does read the id properly and is not confused by the encoded forward slash.

curl https://api.stripe.com/v1/plans/Pro+plan+%24699%2Fmonth \
  -u sk_test_4eC39HqLyjWDarjtT1zdp7dc:

gives:

{
  "error": {
    "code": "resource_missing",
    "doc_url": "https://stripe.com/docs/error-codes/resource-missing",
    "message": "No such plan: Pro plan $699/month",
    "param": "plan",
    "type": "invalid_request_error"
  }
}

Support for error tokens, webhooks and mocked checkout

I work as ruby programmer and I really like the concept of this project. It is great that an official solution like this has emerged. Also, it is fantastic, that one line - changing Stripe.api_base - is enough to run test suite in ruby with the mock server.

However, there are some aspects that refrain me from using it for tests.

The first one is lack of support for error tokens. Maybe I didn't find the proper configuration? Without proper error responses it is difficult to think of using the library in real project for tests, while with VCR it is possible to record Stripe responses in a variety of error cases simply catching tokens with debugger.

The second thing are client-side scripts. By default they call the real Stripe servers. Having a test version of js that called local mock instance would make it possible to write functional tests with Capybara, testing standard payment integration in end-to-end manner. Similar solution is implemented by fake_stripe.

Lastly, support for webhooks would make it possible to test more complicated integrations in functional tests. It would be possible to e.g. test a whole subscription flow with first payment if the mock server sent back a request with event to the app server. I know this would either be limited to only subset of cases or bring relatively big complexity to the library. Still, it seems to me that having only the subset of the cases like creating subscription or charge would make the library more usable. Another option would be to manually trigger webhooks in a similar manner as it is done in stripe-ruby-mock.

I am looking forward for this project to grow as, imho, there is no best option for mocking Stripe integration at the moment. Keep up the good work! :)

Tagging releases for Docker Hub?

First, thank you for stripe-mock! It's unbelievably helpful.

...the v0.30.0 release broke our CI pipeline, as at least one unofficial library is not properly handling GET params, aside from also being pinned to 2018-05-21. There was some mention in #50 of possibly adding tags for docker images -- is this still a possibility?

Crash on concurrent access of resources

I'm using stripe-mock to run a test suite for a Stripe client library for Elixir. I only just realised that stripe-mock responds based on fixtures and does not keep internal state, and so I switched the test suite over to be asynchronous, such that many tests can execute at a time.

However, it seems that stripe-mock cannot handle concurrent access right now. Here is the output with -verbose enabled. It seems to me that the internal fixture map is being accessed at the same time in an unsafe way. I'm not much of a Go programmer so I don't think I can help out much more than that.

This is probably low priority since a simple fix is to just ensure that access is serial, but allowing concurrent access would be good for running large test suites quickly.

Is there ability in stripe-mock to return mock data instead of empty structs?

As the title says, i'm looking for way to use stripe-mock in our application, but for now most of my calls panics or returns error because it gets empty struct and nil pointers.

Is there ability in stripe-mock to return mock data instead of empty structs?

Fix build

Hey Stripe,

We're going to find this very useful. We need to do a few custom things on a fork.

I'm getting a lot of failures on make test:

go test ./...
--- FAIL: TestValidFixtures (0.12s)
    --- FAIL: TestValidFixtures/source (0.00s)
        Error Trace:    8:
    	Error:		No error is expected but got validator 0xc4208e4570 failed: object property 'bitcoin' validation failed: object property 'refund_address' is required

--- FAIL: TestResourcesCanBeGenerated (0.57s)
    --- FAIL: TestResourcesCanBeGenerated/get_/v1/sources/{source}_(without_expansions) (0.00s)
    	generator_test.go:207: Schema is: {
    		  "$ref": "#/components/schemas/source"

I'm glad to PR the fix if you advise me how you want it.

App State

Curious if there are any plans to implement some form of state in stripe-mock. I tried to switch over to using stripe-mock in our test suite, but had to revert once I realized creating tokens then retrieving them would return different data, i.e. card tokens turned into bank accounts when fetched.

I'd be happy to contribute, but I figure keeping state probably requires some discussion about the design and whether or not it aligns with your roadmap.

delete source request returns Account instead of Source

When responding to delete source request, stripe-mock returns an Account object:

$ curl -X DELETE http://localhost:12111/v1/customers/cus_123/sources/src_123 -H "Authorization: Bearer sk_test_123"
{
  "business_logo": null,
  "business_name": null,
  "business_url": null,
  "charges_enabled": false,
  "country": "US",
  "created": 1234567890,
  "debit_negative_balances": true,
  "decline_charge_on": {
    "avs_failure": true,
    "cvc_failure": true
  },
  "default_currency": "usd",
  "details_submitted": false,
  "display_name": null,
  "email": "[email protected]",
  "external_accounts": {
    "data": [
      {
        "account_holder_name": "Jane Austen",
        "account_holder_type": "individual",
        "bank_name": "STRIPE TEST BANK",
        "country": "US",
        "currency": "usd",
        "customer": null,
        "fingerprint": "1JWtPxqbdX5Gamtz",
        "id": "ba_1Djh6mIsTqXCURuYctvSjksI",
        "last4": "6789",
        "metadata": {},
        "object": "bank_account",
        "routing_number": "110000000",
        "status": "new"
      }
    ],
    "has_more": false,
    "object": "list",
    "url": "/v1/accounts/src_123/external_accounts"
  },
  "id": "src_123",
  "legal_entity": {
    "additional_owners": [],
    "address": {
      "city": null,
      "country": "US",
      "line1": null,
      "line2": null,
      "postal_code": null,
      "state": null
    },
    "business_name": null,
    "business_tax_id_provided": false,
    "dob": {
      "day": null,
      "month": null,
      "year": null
    },
    "first_name": null,
    "last_name": null,
    "personal_address": {
      "city": null,
      "country": "US",
      "line1": null,
      "line2": null,
      "postal_code": null,
      "state": null
    },
    "personal_id_number_provided": false,
    "ssn_last_4_provided": false,
    "type": null,
    "verification": {
      "details": null,
      "details_code": null,
      "document": null,
      "document_back": null,
      "status": "unverified"
    }
  },
  "metadata": {},
  "object": "account",
  "payout_schedule": {
    "delay_days": 2,
    "interval": "daily"
  },
  "payout_statement_descriptor": null,
  "payouts_enabled": false,
  "product_description": null,
  "statement_descriptor": null,
  "support_address": null,
  "support_email": null,
  "support_phone": null,
  "timezone": "Etc/UTC",
  "tos_acceptance": {
    "date": null,
    "ip": null,
    "user_agent": null
  },
  "type": "standard",
  "verification": {
    "disabled_reason": "fields_needed",
    "due_by": null,
    "fields_needed": [
      "business_url",
      "external_account",
      "legal_entity.address.city",
      "legal_entity.address.line1",
      "legal_entity.address.postal_code",
      "legal_entity.address.state",
      "legal_entity.dob.day",
      "legal_entity.dob.month",
      "legal_entity.dob.year",
      "legal_entity.first_name",
      "legal_entity.last_name",
      "legal_entity.type",
      "product_description",
      "support_phone",
      "tos_acceptance.date",
      "tos_acceptance.ip"
    ]
  }
}

When responding to delete source request, the live Stripe API returns a Source object:

$ curl -X DELETE https://api.stripe.com/v1/customers/$CUSTOMER_ID/sources/$SOURCE_ID -u $STRIPE_SECRET_KEY:
{
  "id": "src_abc123",
  "object": "source",
  "ach_credit_transfer": {
    "account_number": "test_abc123",
    "bank_name": "TEST BANK",
    "fingerprint": "fIoh668vkTgg7nKU",
    "routing_number": "110000000",
    "swift_code": "TSTEZ122",
    "refund_routing_number": null,
    "refund_account_number": null,
    "refund_account_holder_type": null,
    "refund_account_holder_name": null
  },
  "amount": null,
  "client_secret": "src_client_secret_abc123",
  "created": 1539663457,
  "currency": "usd",
  "flow": "receiver",
  "livemode": false,
  "metadata": {
  },
  "owner": {
    "address": null,
    "email": "[email protected]",
    "name": null,
    "phone": null,
    "verified_address": null,
    "verified_email": null,
    "verified_name": null,
    "verified_phone": null
  },
  "receiver": {
    "address": "110000000-test_abc123",
    "amount_charged": 0,
    "amount_received": 0,
    "amount_returned": 0,
    "refund_attributes_method": "email",
    "refund_attributes_status": "missing"
  },
  "statement_descriptor": null,
  "status": "consumed",
  "type": "ach_credit_transfer",
  "usage": "reusable"
}

Returned association ids are the same for every request

We have run into an issue similar to #152 but for the ids of associations. Our database has a unique constraint on a column where we're storing the charge.id from a payment_intent. This constraint makes it so we cannot use stripe-mock in cases where we take two actions that result in persisting a record with this column as the charge.id is always the same.

Tokens endpoint not properly rejecting bad request body

When sending a body to tokens endpoint to create a bank account for example.

it will validate the headers no problem but as far as the body it's taking any garbage I throw at it and returns successfully when it shouldn't.