boltapp / sleet Goto Github PK

View Code? Open in Web Editor NEW

139.0 51.0 20.0 586 KB

Payment abstraction library - one interface for multiple payment processors ( inspired by Ruby's ActiveMerchant )

License: MIT License

Go 100.00%

payment payment-processing bolt stripe adyen braintree cybersource authorizenet

sleet's Introduction

Sleet

Payment abstraction library - interact with different Payment Service Providers (PsP) with one unified interface.

Installation

go get github.com/BoltApp/sleet

Methodology

Wherever possible, we try to use native Golang implementations of the PsP's API. We also assume that the caller can pass along raw credit card information (i.e. are PCI compliant)

Supported Gateway API Calls

Authorize
Capture
Void
Refund

Webhooks Support

We support abstracting PsP Webhook notifications into a common interface.

PsP Support Matrix

PsP	Gateway APIs	Webhooks
Adyen	✅	❌
Authorize.Net	✅	❌
Braintree	✅	❌
CyberSource	✅	❌
Checkout.com	✅	❌
FirstData	✅	❌
NMI	✅	❌
Orbital	✅	❌
RocketGate	✅	❌
Stripe	✅	❌

To run tests

Unit test

go test -v -tags=unit $(go list ./... | grep -v integration-tests)

Integration test

The following environment variables are needed in order to run tests

$ export ADYEN_USERNAME="YOUR_ADYEN_WEBSERVICE_USERNAME"
$ export ADYEN_ACCOUNT="YOUR_ADYEN_MERCHANT_ACCOUNT"
$ export ADYEN_PASSWORD="YOUR_ADYEN_WEBSERVICE_PASSWORD"
$ export STRIPE_TEST_KEY="YOUR_STRIPE_API_KEY"
$ export AUTH_NET_LOGIN_ID="YOUR_AUTHNET_LOGIN"
$ export AUTH_NET_TXN_KEY="YOUR_AUTHNET_TXN_KEY"
$ export BRAINTREE_MERCHANT_ID="YOUR_BRAINTREE_MERCHANT_ACCOUNT"
$ export BRAINTREE_PUBLIC_KEY="YOUR_BRAINTREE_PUBLIC_KEY"
$ export BRAINTREE_PRIVATE_ID="YOUR_BRAINTREE_PRIVATE_KEY"
$ export CYBERSOURCE_ACCOUNT="YOUR_CYBS_ACCOUNT"
$ export CYBERSOURCE_API_KEY="YOUR_CYBS_KEY"
$ export CYBERSOURCE_SHARED_SECRET="YOUR_CYBS_SECRET"
$ export NMI_SECURITY_KEY="YOUR_NMI_PRIVATE_KEY"
$ export CHECKOUTCOM_TEST_KEY="YOUR_CHECKOUTCOM_PRIVATE_KEY"
$ export CHECKOUTCOM_TEST_KEY_WITH_PCID="YOUR_CHECKOUTCOM_PRIVATE_KEY_WITH_PROCESSING_CHANNEL_ID"
$ export CHECKOUTCOM_TEST_PCID="YOUR_CHECKOUTCOM_PROCESSING_CHANNEL_ID"

Then run tests with: go test ./integration-tests/

Code Example for Auth + Capture

import (
  "github.com/BoltApp/sleet"
  "github.com/BoltApp/sleet/gateways/authorize_net"
)
// Generate a client using your own credentials
client := authorize_net.NewClient("AUTH_NET_LOGIN_ID", "AUTH_NET_TXN_KEY")

amount := sleet.Amount{
  Amount: 100,
  Currency: "USD",
}
card := sleet.CreditCard{
  FirstName: "Bolt",
  LastName: "Checkout",
  Number: "4111111111111111",
  ExpMonth: 8,
  EpxYear: 2010,
  CVV: "000",
}
streetAddress := "22 Linda St."
locality := "Hoboken"
regionCode := "NJ"
postalCode := "07030"
countryCode := "US"
address := sleet.BillingAddress{
  StreetAddress1: &streetAddress,
  Locality:       &locality,
  RegionCode:     &regionCode,
  PostalCode:     &postalCode,
  CountryCode:    &countryCode,
}
// To get specific response headers, add them to the request options.
// They will be attached to the AuthorizationResponse
options := make(map[string]interface{})
options["ResponseHeader"] = []string{"x-test-header"}
authorizeRequest := sleet.AuthorizationRequest{
  Amount: &amount,
  CreditCard: &card,
  BillingAddress: &address,
  Options: options,
}
authorizeResponse, _ := client.Authorize(&authorizeRequest)

captureRequest := sleet.CaptureRequest{
  Amount:               &amount,
  TransactionReference: authorizeResponse.TransactionReference,
}
client.Capture(&captureRequest)

sleet's People

Contributors

Stargazers

Watchers

sleet's Issues

Adyen: Support for application information

I would like to propose adding support for including application information scoped specifically to direct integrations. See this page for more details.

Given that this project abstracts the direct integration approach, I propose adding support for the applicationInfo.externalPlatform request parameter for now. As a first approach, I propose sending the following JSON payload for externalPlatform:

{
  "externalPlatform": {
    "name": "<PlatformName>",
    "version": "<LibraryVersion>",
    "integrator": "<IntegratorName>"
  }
}

Clients using this library should specify a value for each key name via environment variables. If no such value is provided, we do not send a value to Adyen.

The benefit of addressing this issue allows merchants utilizing this library to identify themselves to Adyen as well as facilitating integration troubleshooting. Furthermore, Adyen uses this information to resolve merchant and integrator referral fees.

I am open to further conversation about this issue and would be delighted to begin implementation if no concerns and/or objections are raised.

Security Policy violation SECURITY.md

This issue was automatically created by Allstar.

Security Policy Violation
Security policy not enabled.
A SECURITY.md file can give users information about what constitutes a vulnerability and how to report one securely so that information about a bug is not publicly visible. Examples of secure reporting methods include using an issue tracker with private issue support, or encrypted email with a published key.

To fix this, add a SECURITY.md file that explains how to handle vulnerabilities found in your repository. Go to https://github.com/BoltApp/sleet/security/policy to enable.

For more information, see https://docs.github.com/en/code-security/getting-started/adding-a-security-policy-to-your-repository.

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Security Policy violation Branch Protection

This issue was automatically created by Allstar.

Security Policy Violation
Dismiss stale reviews not configured for branch master

This issue will auto resolve when the policy is in compliance.

Issue created by Allstar. See https://github.com/ossf/allstar/ for more information. For questions specific to the repository, please contact the owner or maintainer.

Scope and roadmap

Hi!

Thank you for building and actively maintaining this library.
Before using it, I would like to know:

What is the scope of the library? (What features will you add? Do you plan to support recurring billing?)
Do you have a roadmap for webhooks / additional features?
Is this viable for production use?

Thanks.

Feature Request - Redirect Gateway Support

👋

I would like to request a feature to support merchants are using PSP hosted platforms like PayPal, for example, where the process involves a redirect to the PSP, and then a callback.

I would like to start working on a PR for this but am looking for some guidance on how best to implement the feature. My main concern is with managing the redirect. Should the integration provide the callback URL, or simply take it as a parameter to pass onto the PSP? The parameter passing is simpler, but then it just acts like a very thin API; not sure if there is much value in that?

If the integration should also host the callback, then there is a need to manage ports/APIs and configuration around that.

Appreciate any thoughts on this.