Versioning with stripe-go

In this episode, you’ll learn from Dawn about API versioning with the Stripe API, and how each version of stripe-go is pinned to a specific API version. You’ll also see the differences between some responses returned from the API for different versions and how they impact the shape of webhook notification payloads.

Resources

Official client library: https://github.com/stripe/stripe-go
Official documentation: https://stripe.com/docs/api/versioning
Code: https://github.com/stripe-samples/developer-office-hours/tree/master/2020-10-30-client-libraries/go/versioning.go

Table of contents

00:00 Overview
00:46 Version definitions
01:45 How API changes work with Stripe
02:48 Account versions
03:24 Print the pinned API version
04:11 See the same customer object with two API versions
09:00 Create a webhook endpoint for a specific API version

#stripe-go #go

What is GEEK

Buddha Community

What's new in the go 1.15

Go announced Go 1.15 version on 11 Aug 2020. Highlighted updates and features include Substantial improvements to the Go linker, Improved allocation for small objects at high core counts, X.509 CommonName deprecation, GOPROXY supports skipping proxies that return errors, New embedded tzdata package, Several Core Library improvements and more.

As Go promise for maintaining backward compatibility. After upgrading to the latest Go 1.15 version, almost all existing Golang applications or programs continue to compile and run as older Golang version.

#go #golang #go 1.15 #go features #go improvement #go package #go new features

Versioning with stripe-go

In this episode, you’ll learn from Dawn about API versioning with the Stripe API, and how each version of stripe-go is pinned to a specific API version. You’ll also see the differences between some responses returned from the API for different versions and how they impact the shape of webhook notification payloads.

Resources

Official client library: https://github.com/stripe/stripe-go
Official documentation: https://stripe.com/docs/api/versioning
Code: https://github.com/stripe-samples/developer-office-hours/tree/master/2020-10-30-client-libraries/go/versioning.go

Table of contents

00:00 Overview
00:46 Version definitions
01:45 How API changes work with Stripe
02:48 Account versions
03:24 Print the pinned API version
04:11 See the same customer object with two API versions
09:00 Create a webhook endpoint for a specific API version

#stripe-go #go

How to Create Customer Balances for Spark Laravel & Stripe

Introduction

In the following documentation, we will discuss how to configure a Laravel Spark installation when using the Stripe (opens new window)payment provider. All of Spark's configuration options are housed in your application's config/spark.php configuration file.

#Stripe Configuration

Of course, to use Stripe as a payment provider for your Laravel Spark application you must have an active Stripe account (opens new window).

#Environment Variables

Next, you should configure the application environment variables that will be needed by Spark in order to access your Stripe account. These variables should be placed in your application's .env environment file.

Of course, you should adjust the variable's values to correspond to your own Stripe account's credentials. Your Stripe API credentials and public key are available in your Stripe account dashboard:

CASHIER_CURRENCY=USD
CASHIER_CURRENCY_LOCALE=en
STRIPE_KEY=pk_test_example
STRIPE_SECRET=sk_test_example
STRIPE_WEBHOOK_SECRET=sk_test_example

Configuring Locales

In order to use locales other than en, ensure the ext-intl PHP extension is installed and configured on your server.

#Stripe Webhooks

In addition, your Spark powered application will need to receive webhooks from Stripe in order to keep your application's billing and subscription data in sync with Stripe's. Within your Stripe dashboard's webhook management panel, you should configure Stripe to send webhook alerts to your application's /spark/webhook URI. You should enable webhook alerts for the following events:

• customer.deleted
• customer.subscription.created
• customer.subscription.deleted
• customer.subscription.updated
• customer.updated
• invoice.payment_action_required
• invoice.payment_succeeded

#Webhooks & Local Development

For Stripe to be able to send your application webhooks during local development, you will need to expose your application via a site sharing service such as Ngrok (opens new window)or Expose (opens new window). If you are developing your application locally using Laravel Sail (opens new window), you may use Sail's site sharing command (opens new window).

#Configuring Billables

Spark allows you to define the types of billable models that your application will be managing. Most commonly, applications bill individual users for monthly and yearly subscription plans. However, your application may choose to bill some other type of model, such as a team, organization, band, etc. The Stripe edition of Spark currently only supports a single billable model entity (team, user, etc.) per application.

You may define your billable models within the billables array of your application's spark configuration file. By default, this array contains an entry for the App\Models\User model. If the billable model is something other than App\Models\User, you should invoke Cashier's useCustomerModel method in the boot method of your AppServiceProvider class in order to inform Cashier of your custom model:

use App\Entities\User;
use Laravel\Cashier\Cashier;
 
/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Cashier::useCustomerModel(User::class);
}

Before continuing, you should ensure that the model class that corresponds to your billable model is using the Spark\Billable trait and that it casts the trial_ends_at attribute to datetime:

<?php

namespace App\Models;

use Illuminate\Database\Eloquent\Factories\HasFactory;
use Illuminate\Foundation\Auth\User as Authenticatable;
use Illuminate\Notifications\Notifiable;
use Spark\Billable;

class User extends Authenticatable
{
    use Billable, HasFactory, Notifiable;

    protected $casts = [
        'trial_ends_at' => 'datetime',
    ];

}

#Billable Slugs

As you may have noticed, each entry in the billables configuration array is keyed by a "slug" that is a shortened form of the billable model class. This slug can be used when accessing the Spark customer billing portal, such as https://example.com/billing/user or https://example.com/billing/team.

#Billable Resolution

When you installed Laravel Spark, an App\Providers\SparkServiceProvider class was created for you. Within this service provider, you will find a callback that is used by Spark to resolve the billable model instance when accessing the Spark billing portal. By default, this callback simply returns the currently authenticated user, which is the desired behavior for most applications using Laravel Spark:

use App\Models\User;
use Illuminate\Http\Request;
use Spark\Spark;

Spark::billable(User::class)->resolve(function (Request $request) {
    return $request->user();
});

However, if your application is not billing individual users, you may need to adjust this callback. For example, if your application offers team billing instead of user billing, you might customize the callback like so:

use App\Models\Team;
use Illuminate\Http\Request;
use Spark\Spark;

Spark::billable(Team::class)->resolve(function (Request $request) {
    return $request->user()->currentTeam;
});

#Billable Authorization

Next, let's examine the authorization callbacks that Spark will use to determine if the currently authenticated user of your application is authorized to view the billing portal for a particular billable model.

When you installed Laravel Spark, an App\Providers\SparkServiceProvider class was created for you. Within this service provider, you will find the authorization callback definition used to determine if a given user is authorized to view the billing portal for the App\Models\User billable class. Of course, if your application is not billing users, you should update the billable class and authorization callback logic to fit your application's needs. By default, Spark will simply verify that the currently authenticated user can only manage its own billing settings:

use App\Models\User;
use Illuminate\Http\Request;
use Spark\Spark;

Spark::billable(User::class)->authorize(function (User $billable, Request $request) {
    return $request->user() &&
           $request->user()->id == $billable->id;
});

If the authorization callback returns true, the currently authenticated user will be authorized to view the billing portal and manage the billing settings for the given $billable model. If the callback returns false, the request to access the billing portal will be denied.

You are free to customize the authorize callback based on your own application's needs. For example, if your application bills teams instead of individual users, you might update the callback like so:

use App\Models\Team;
use Illuminate\Http\Request;
use Spark\Spark;

Spark::billable(Team::class)->authorize(function (Team $billable, Request $request) {
    return $request->user() &&
           $request->user()->ownsTeam($billable);
});

#Defining Subscription Plans

As we previously discussed, Spark allows you to define the types of billable models that your application will be managing. These billable models are defined within the billables array of your application's config/spark.php configuration file:

Each billable configuration within the billables array contains a plans array. Within this array you may configure each of the billing plans offered by your application to that particular billable type. The monthly_id and yearly_id identifiers should correspond to the price / plan identifiers configured within your Stripe account dashboard:

use App\Models\User;

'billables' => [
    'user' => [
        'model' => User::class,
        'trial_days' => 5,
        'plans' => [
            [
                'name' => 'Standard',
                'short_description' => 'This is a short, human friendly description of the plan.',
                'monthly_id' => 'price_id',
                'yearly_id' => 'price_id',
                'features' => [
                    'Feature 1',
                    'Feature 2',
                    'Feature 3',
                ],
            ],
        ],
    ],
]

If your subscription plan only offers a monthly billing cycle, you may omit the yearly_id identifier from your plan configuration. Likewise, if your plan only offers a yearly billing cycle, you may omit the monthly_id identifier.

In addition, you are free to supply a short description of the plan and a list of features relevant to the plan. This information will be displayed in the Spark billing portal.

#Accessing The Billing Portal

Once you have configured your Spark installation, you may access your application's billing portal at the /billing URI. So, if your application is being served on localhost, you may access your application's billing portal at http://localhost/billing.

Of course, you may link to the billing portal from your application's dashboard however you see fit:

<a href="/billing">
    Manage Subscription
</a>

#Showing A Link To The Terms And Conditions

Many applications display billing terms and conditions during checkout. Spark allows you to easily do the same within your application's billing portal. To get started, add a terms_url configuration value in your application's config/spark.php configuration file:

'terms_url' => '/terms'

Once added, Spark will display a link pointing to /terms in the billing portal.

#Customer Balance Top Ups

Spark Stripe allows your customers to "top up" their balance. This feature can prove useful if your customer's cards do not support recurring payments, such as customers under India's RBI regulations.

To get started, you will need to create a special product and price in your Stripe Dashboard. So, create a product called "Balance Top Up" and add a price to the product that utilizes the "Customer chooses price" Stripe pricing model. After creating the product and price, define the price ID as an environment variable in your application's .env file:

SPARK_TOP_UP_PRICE=price_xxx

After defining the environment variable, enable the top up feature using its corresponding feature flag in your application's config/spark.php configuration file:

'features' => [
    ...
    Features::topups(['price' => env('SPARK_TOPUP_PRICE')]),
    ...
],

Once this feature has been enabled, the balance top up button will be shown in the Spark billing portal. After clicking the balance top up button, the customer will be redirected to a Stripe Checkout session where they can choose the monetary amount they wish to add to their account. Once the customer has completed the Checkout session, the customer will be redirected back to the Spark billing portal and their balance will be updated. You should ensure that your Stripe webhooks are configured to dispatch the checkout.session.completed event.

Invoices are not generated for balance top ups, as invoicing only occurs when the billing cycle renews. Customers that need a refund for a balance top up will need to contact your application's customer support, and the charge can then be refunded manually from the Stripe dashboard.

Link: https://spark.laravel.com/docs/2.x/spark-stripe/configuration.html

#stripe #laravel #php

How to Use Metadata with Stripe-go

Metadata is useful for storing additional, structured information on an object. As an example, you could store your user's full name and corresponding unique identifier from your system on a Stripe Customer object. Metadata is not used by Stripe—for example, not used to authorize or decline a charge—and won't be seen by your users unless you choose to show it to them. In this video Dawn shows you how to work with metadata from the Stripe API.

#stripe #go 

Govvv: "go Build" Wrapper to Add Version info To Golang Applications

govvv

The simple Go binary versioning tool that wraps the go build command.

Stop worrying about -ldflags and go get github.com/ahmetb/govvv now.

Build Variables

Variable	Description	Example
main.GitCommit	short commit hash of source tree	0b5ed7a
main.GitBranch	current branch name the code is built off	master
main.GitState	whether there are uncommitted changes	clean or dirty
main.GitSummary	output of git describe --tags --dirty --always	v1.0.0,  v1.0.1-5-g585c78f-dirty,  fbd157c
main.BuildDate	RFC3339 formatted UTC date	2016-08-04T18:07:54Z
main.Version	contents of ./VERSION file, if exists, or the value passed via the -version option	2.0.0

Using govvv is easy

Just add the build variables you want to the main package and run:

old	:sparkles: new :sparkles:
go build	govvv build
go install	govvv install

Version your app with govvv

Create a VERSION file in your build root directory and add a Version variable to your main package.

Do you have your own way of specifying Version? No problem:

govvv lets you specify custom -ldflags

Your existing -ldflags argument will still be preserved:

govvv build -ldflags "-X main.BuildNumber=$buildnum" myapp

and the -ldflags constructed by govvv will be appended to your flag.

Don’t want to depend on govvv? It’s fine!

You can just pass a -print argument and govvv will just print the go build command with -ldflags for you and will not execute the go tool:

$ govvv build -print
go build \
    -ldflags \
    "-X main.GitCommit=57b9870 -X main.GitBranch=dry-run -X main.GitState=dirty -X main.Version=0.1.0 -X main.BuildDate=2016-08-08T20:50:21Z"

Still don’t want to wrap the go tool? Well, try -flags to retrieve the LDFLAGS govvv prepares:

$ go build -ldflags="$(govvv -flags)"

Want to use a different package?

You can pass a -pkg argument with the full package name, and govvv will set the build variables in that package instead of main. For example:

# build with govvv
$ govvv build -pkg github.com/myacct/myproj/mypkg

# build with go
$ go build -ldflags="$(govvv -flags -pkg $(go list ./mypkg))"

Want to use a different version?

You can pass a -version argument with the desired version, and govvv will use the specified version instead of obtaining it from the ./VERSION file. For example:

# build with govvv
$ govvv build -version 1.2.3

# build with go
$ go build -ldflags="$(govvv -flags -version 1.2.3)"

Try govvv today

$ go get github.com/ahmetb/govvv

---

Author: Ahmetb
Source Code: https://github.com/ahmetb/govvv 
License: Apache-2.0 license

#go #golang #version