Research
Security News
Malicious npm Packages Inject SSH Backdoors via Typosquatted Libraries
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
github.com/stripe/stripe-go/v71
The official Stripe Go client library.
Make sure your project is using Go Modules (it will have a go.mod
file in its
root if it already is):
go mod init
Then, reference stripe-go in a Go program with import
:
import (
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/customer"
)
Run any of the normal go
commands (build
/install
/test
). The Go
toolchain will resolve and fetch the stripe-go module automatically.
Alternatively, you can also explicitly go get
the package into a project:
go get -u github.com/stripe/stripe-go/v71
For a comprehensive list of examples, check out the API documentation.
For details on all the functionality in this library, see the GoDoc documentation.
Below are a few simple examples:
params := &stripe.CustomerParams{
Description: stripe.String("Stripe Developer"),
Email: stripe.String("gostripe@stripe.com"),
}
customer, err := customer.New(params)
params := &stripe.PaymentIntentListParams{
Customer: stripe.String(customer.ID),
}
// set this so you can easily retry your request in case of a timeout
params.Params.IdempotencyKey = stripe.NewIdempotencyKey()
i := paymentintent.List(params)
for i.Next() {
pi := i.PaymentIntent()
}
if err := i.Err(); err != nil {
// handle
}
i := event.List(nil)
for i.Next() {
e := i.Event()
// access event data via e.GetObjectValue("resource_name_based_on_type", "resource_property_name")
// alternatively you can access values via e.Data.Object["resource_name_based_on_type"].(map[string]interface{})["resource_property_name"]
// access previous attributes via e.GetPreviousValue("resource_name_based_on_type", "resource_property_name")
// alternatively you can access values via e.Data.PrevPreviousAttributes["resource_name_based_on_type"].(map[string]interface{})["resource_property_name"]
}
Alternatively, you can use the event.Data.Raw
property to unmarshal to the
appropriate struct.
There are two ways of authenticating requests when performing actions on behalf
of a connected account, one that uses the Stripe-Account
header containing an
account's ID, and one that uses the account's keys. Usually the former is the
recommended approach. See the documentation for more information.
To use the Stripe-Account
approach, use SetStripeAccount()
on a ListParams
or Params
class. For example:
// For a list request
listParams := &stripe.CustomerListParams{}
listParams.SetStripeAccount("acct_123")
// For any other kind of request
params := &stripe.CustomerParams{}
params.SetStripeAccount("acct_123")
To use a key, pass it to API
's Init
function:
import (
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/client"
)
stripe := &client.API{}
stripe.Init("access_token", nil)
If you're running the client in a Google AppEngine environment, you'll need to
create a per-request Stripe client since the http.DefaultClient
is not
available. Here's a sample handler:
import (
"fmt"
"net/http"
"google.golang.org/appengine"
"google.golang.org/appengine/urlfetch"
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/client"
)
func handler(w http.ResponseWriter, r *http.Request) {
c := appengine.NewContext(r)
httpClient := urlfetch.Client(c)
sc := stripeClient.New("sk_test_123", stripe.NewBackends(httpClient))
params := &stripe.CustomerParams{
Description: stripe.String("Stripe Developer"),
Email: stripe.String("gostripe@stripe.com"),
}
customer, err := sc.Customers.New(params)
if err != nil {
fmt.Fprintf(w, "Could not create customer: %v", err)
}
fmt.Fprintf(w, "Customer created: %v", customer.ID)
}
While some resources may contain more/less APIs, the following pattern is
applied throughout the library for a given $resource$
:
If you're only dealing with a single key, you can simply import the packages required for the resources you're interacting with without the need to create a client.
import (
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/$resource$"
)
// Setup
stripe.Key = "sk_key"
stripe.SetBackend("api", backend) // optional, useful for mocking
// Create
$resource$, err := $resource$.New(stripe.$Resource$Params)
// Get
$resource$, err := $resource$.Get(id, stripe.$Resource$Params)
// Update
$resource$, err := $resource$.Update(stripe.$Resource$Params)
// Delete
resourceDeleted, err := $resource$.Del(id, stripe.$Resource$Params)
// List
i := $resource$.List(stripe.$Resource$ListParams)
for i.Next() {
$resource$ := i.$Resource$()
}
if err := i.Err(); err != nil {
// handle
}
If you're dealing with multiple keys, it is recommended you use client.API
.
This allows you to create as many clients as needed, each with their own
individual key.
import (
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/client"
)
// Setup
sc := &client.API{}
sc.Init("sk_key", nil) // the second parameter overrides the backends used if needed for mocking
// Create
$resource$, err := sc.$Resource$s.New(stripe.$Resource$Params)
// Get
$resource$, err := sc.$Resource$s.Get(id, stripe.$Resource$Params)
// Update
$resource$, err := sc.$Resource$s.Update(stripe.$Resource$Params)
// Delete
resourceDeleted, err := sc.$Resource$s.Del(id, stripe.$Resource$Params)
// List
i := sc.$Resource$s.List(stripe.$Resource$ListParams)
for i.Next() {
resource := i.$Resource$()
}
if err := i.Err(); err != nil {
// handle
}
Use LastResponse
on any APIResource
to look at the API response that
generated the current object:
coupon, err := coupon.New(...)
requestID := coupon.LastResponse.RequestID
Similarly, for List
operations, the last response is available on the list
object attached to the iterator:
it := coupon.List(...)
for it.Next() {
// Last response *NOT* on the individual iterator object
it.Coupon().LastResponse // wrong
// But rather on the list object, also accessible through the iterator
requestID := it.CouponList().LastResponse.RequestID
}
See the definition of APIResponse
for available fields.
Note that where API resources are nested in other API resources, only
LastResponse
on the top-level resource is set.
The library automatically retries requests on intermittent failures like on a
connection error, timeout, or on certain API responses like a status 409 Conflict
. Idempotency keys are always added to requests to
make any such subsequent retries safe.
By default, it will perform up to two retries. That number can be configured
with MaxNetworkRetries
:
import (
"github.com/stripe/stripe-go/v71"
"github.com/stripe/stripe-go/v71/client"
)
config := &stripe.BackendConfig{
MaxNetworkRetries: stripe.Int64(0), // Zero retries
}
sc := &client.API{}
sc.Init("sk_key", &stripe.Backends{
API: stripe.GetBackendWithConfig(stripe.APIBackend, config),
Uploads: stripe.GetBackendWithConfig(stripe.UploadsBackend, config),
})
coupon, err := sc.Coupons.New(...)
By default, the library logs error messages only (which are sent to stderr
).
Configure default logging using the global DefaultLeveledLogger
variable:
stripe.DefaultLeveledLogger = &stripe.LeveledLogger{
Level: stripe.LevelInfo,
}
Or on a per-backend basis:
config := &stripe.BackendConfig{
LeveledLogger: &stripe.LeveledLogger{
Level: stripe.LevelInfo,
},
}
It's possible to use non-Stripe leveled loggers as well. Stripe expects loggers to comply to the following interface:
type LeveledLoggerInterface interface {
Debugf(format string, v ...interface{})
Errorf(format string, v ...interface{})
Infof(format string, v ...interface{})
Warnf(format string, v ...interface{})
}
Some loggers like Logrus and Zap's SugaredLogger
support this interface out-of-the-box so it's possible to set
DefaultLeveledLogger
to a *logrus.Logger
or *zap.SugaredLogger
directly.
For others it may be necessary to write a thin shim layer to support them.
All expandable objects in stripe-go take the form of a
full resource struct, but unless expansion is requested, only the ID
field of
that struct is populated. Expansion is requested by calling AddExpand
on
parameter structs. For example:
//
// *Without* expansion
//
c, _ := charge.Retrieve("ch_123", nil)
c.Customer.ID // Only ID is populated
c.Customer.Name // All other fields are always empty
//
// With expansion
//
p := &CustomerParams{}
p.AddExpand("customer")
c, _ := charge.Retrieve("ch_123", p)
c.Customer.ID // ID is still available
c.Customer.Name // Name is now also available (if it had a value)
If you're writing a plugin that uses the library, we'd appreciate it if you
identified using stripe.SetAppInfo
:
stripe.SetAppInfo(&stripe.AppInfo{
Name: "MyAwesomePlugin",
URL: "https://myawesomeplugin.info",
Version: "1.2.34",
})
This information is passed along when the library makes calls to the Stripe
API. Note that while Name
is always required, URL
and Version
are
optional.
By default, the library sends request latency telemetry to Stripe. These numbers help Stripe improve the overall latency of its API for all users.
You can disable this behavior if you prefer:
config := &stripe.BackendConfig{
EnableTelemetry: stripe.Bool(false),
}
Pull requests from the community are welcome. If you submit one, please keep the following guidelines in mind:
go fmt
compliant.make test
succeeds.The test suite needs testify's require
package to run:
github.com/stretchr/testify/require
Before running the tests, make sure to grab all of the package's dependencies:
go get -t -v
It also depends on stripe-mock, so make sure to fetch and run it from a background terminal (stripe-mock's README also contains instructions for installing via Homebrew and other methods):
go get -u github.com/stripe/stripe-mock
stripe-mock
Run all tests:
make test
Run tests for one package:
go test ./invoice
Run a single test:
go test ./invoice -run TestInvoiceGet
For any requests, bug or comments, please open an issue or submit a pull request.
FAQs
Unknown package
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Research
Security News
Socket’s threat research team has detected six malicious npm packages typosquatting popular libraries to insert SSH backdoors.
Security News
MITRE's 2024 CWE Top 25 highlights critical software vulnerabilities like XSS, SQL Injection, and CSRF, reflecting shifts due to a refined ranking methodology.
Security News
In this segment of the Risky Business podcast, Feross Aboukhadijeh and Patrick Gray discuss the challenges of tracking malware discovered in open source softare.