GoodFunds Gateway - RESTful API Documentation

Getting Started

RESTful API

GoodFunds Gateway API is a secure, server based engine that provides support for transaction processing in real-time. Our RESTful API supports different formats available to use as listed below.

If you don't currently have an account with us than you can Request An Account Here

  • xml - almost any programming language can read XML
  • json - useful for JavaScript and increasingly PHP apps. [ Default format ]

This means your URLs can look like this:
https://demo.goodfundsgateway.com/api/clients.json
https://demo.goodfundsgateway.com/api/clients?format=json

This guide will focus on the RESTful API through the use of an integrated application.

View On Postman

Benefits

  • Submit transactions.
  • Manage your payment account.
  • Multi-supported gateways.

Features

  • Full range of payment types including:
    • Credit card
    • Electronic checks and ACH
  • Recurring and installment transactions
  • Credit card tokenization enabled

The integration to the SVS gateway supports transactions for both card present and non-present environments, including:

  • E-commerce ( online )
  • Mail order ( back office mail and phone )

Use SVS as a backend feature to your integrated application, completely transparent to your customers.

Getting Started

This section provides some basic information that you may need before you are able to use SVS.

  • Getting a unique test account
  • URLS
  • Authentication

Getting a unique test account

Prior to beginning SVS integration, integrators must request a unique test account, all transaction must be submitted via HTTPS in order to perform transactions from an integrated solution.

Contact GoodFunds Gateway RESTful API support group at sales@goodfundsgateway.com or (866) 927-7180 to submit your request for a test account.

The following information must be provided to the support group:

  • Company Name
  • Primary contact name
  • Primary contact phone
  • Primary email address
  • Brief description of use of RESTful API

URLS

All reference of URLs [Insert URL Here] in samples must be replaced with the following:

Demo URL

  • https://demo.goodfundsgateway.com/api

Live URL

  • https://live.goodfundsgateway.com/api

Authentication

The RESTful API fields that comprise the sensitive processing credentials and are required to be passed through the header for each request are:

Field Name Description
SVS-API-ID SVS API ID as provided by GoodFunds Gateway
SVS-API-KEY SVS KEY as configured on Secure Vault System (case sensitive)

Important:

  • The SVS-API-ID is provided for associating with their company using the RESTful API.
  • The SVS-API-KEY is a per user instance configured for each user that is using the SVS RESTful API.

All sensitive data, specifically your SVS credentials, must be placed in server side code rather than placing hidden value fields an HTML form. This will limit the ability of malicious users to edit and use this data for their own fraudulent purposes. The use of server side scripting allows your sesnitive data to never be visible by others on your website.

Method References

GET

Used to fetch information about an existing resource.

POST

Used to update an existing resource with information or create a resource.

Server Response Codes

  • 200 (OK) confirms the success of a GET, PUT, or DELETE request.
  • 201 (Created) confirms the success of a POST request.
  • 304 (Not Modified) is used by a conditional GET to inform the client that the resource has not been modified.
  • 400 (Bad Request) indicates a malformed request, often for a POST or PUT in which the request’s content is invalid.
  • 401 (Unauthorized) is used to indicate that authentication is required.
  • 403 (Forbidden) indicates that the client is not authorized for the requested action.
  • 404 (Not Found) is used to respond to any request to indicate that the resource could not be found.
  • 405 (Method Not Allowed) informs the client the that requested HTTP method is not available for that resource.
  • 409 (Conflict) should be used for situations where there is a conflict which prevents the service to perform the operation, but there is still a chance that the client might be able to resolve the conflict and resubmit the request.