Ruby SDK

To create payments, you need to link your server to our platform via one of our integration methods.
Our Ruby SDK library is the ideal solution to connect to our platform if you prefer to do so with your own stand-alone system using Ruby language.

Choosing the Ruby SDK, you can:

• Access all functionalities of our RESTful API in a compact, convenient and customisable way.
• Use all server-sided integration methods of our platform (Hosted Checkout Page / Hosted Tokenization Page / Server-to-server).
• Make all payment processing-related API calls (i.e. CreateHostedCheckout, CreatePayment, RefundPayment and many more).

To take full advantage of this SDK, make sure you meet these requirements:

• Ruby 2.3 or higher

Install the latest version of the Ruby SDK using GEM package manager by running:

gem install onlinepayments-sdk-ruby

Find more details on GitHub. Also, check out all available SDK objects and properties in our Full API Reference. Once you are all set, read the next chapters on how to prepare and use the SDK.

Initialisation

To connect your system to our platform by using the SDK, you need to initialise it at first.

Initialising the SDK requires you to:

• Create test/live account.
• Create a configuration file with properties.
  
  

  ---
  onlinePayments.api.integrator: integrator
  onlinePayments.api.endpoint.host: apiEndpoint
  # The following keys are optional and use the given value by default.
  onlinePayments.api.endpoint.scheme: https
  onlinePayments.api.endpoint.port: -1
  onlinePayments.api.connectTimeout: 5
  onlinePayments.api.socketTimeout: 300
  onlinePayments.api.maxConnections: 10
  onlinePayments.api.authorizationType: v1HMAC

• Create an API Key and API Secret for the PSPID you wish to use for transaction processing.
• Initialise an instance of Client / MerchantClient using the API Key / API Secret to set up the connection to our test/live platform.
  

  
  require 'onlinepayments/sdk'
  include OnlinePayments::SDK
  
  client = Factory.create_client_from_file(configuration_file_name, apiKey, apiSecret)
  merchant_client = client.merchant(merchantId)

The following table provides an overview of the arguments accepted by the individual instances:

After initialisation, you can send requests to our platform via your PSPID. Learn how to do this in the next chapter.

Use SDK

After the successful initialisation of the Client instance, you gain full access to our RESTful API. It enables you to:

• Send requests for new transactions for any of our server integration methods.
• Get your transactions’ current status.
• Perform maintenance requests (i.e., captures, refunds) on existing transactions.

This call returns a CreateHostedCheckoutResponse response. Store the hostedCheckoutId and RETURNMAC it contains, as well as any other information relevant for you. You will need these for steps described in the following chapters.

This response also contains a partialRedirectURL.

You have to concatenate the base URL "https://payment." with partialRedirectURL according to the formula

https://payment. + partialRedirectURL

and perform a redirection of your customer to this URL. Once the customer visits the Hosted Checkout Page, the payment process continues there.

Check out our test cases in GitHub, including full code samples, and our Full API Reference to learn what is possible.

Below you may find some of the most common actions you can perform:

• Create new transactions
• Get transaction status
• Perform maintenance operation

Create new transactions

To create a new transaction, you can use a Client or MerchantClient instance for any of our integration methods to create a new transaction. It can be done through:

• Routing the request to your PSPID on our platform (for Client).
• Creating a request for the respective integration method.

Below you can find code samples related to particular integration methods:

• Hosted Checkout Page
• Hosted Tokenization Page
• Server-to-server

Hosted Checkout Page

To use this integration method, you need to create a CreateHostedCheckoutRequest call. It must contain at least an Order object.

# Initialisation ...

include OnlinePayments::SDK::Domain
 
order_hash = {
  "order" => {"amountOfMoney" => {"currencyCode" => "EUR", "amount" => 123}}
}
 
hosted_checkout_client = merchant_client.hosted_checkout()
hosted_checkout = CreateHostedCheckoutRequest.new()
hosted_checkout.from_hash(order_hash)
response = hosted_checkout_client.create_hosted_checkout(hosted_checkout)

Hosted Tokenization Page

To use this integration method, you need to

• Create and upload a template as described in our Hosted Tokenization Page guide. It must contain at least an Order object.

# Initialisation ...
include OnlinePayments::SDK::Domain
 
request = CreateHostedTokenizationRequest.new()
request.from_hash({"variant" => "template.html"})
hosted_t_client = merchant_client.hosted_tokenization()
response = hosted_t_client.create_hosted_tokenization(request)

From response retrieve hosted_tokenizationId and partial_redirect_url:

t_id = response.hosted_tokenization_id
url = response.partial_redirect_url

Use the partial_redirect_url for the iframe and the hosted_tokenizationId or tokenId (see infobox) to create the actual payment via Server-to-server integration method.

token = hosted_t_client.get_hosted_tokenization(t_id).token.id
# Hash with all needed data for payment request
 payment_hash = {
    "order" => {
      "amountOfMoney" => {
        "currencyCode" => "EUR", 
        "amount" => 12300}},
    "CardPaymentMethodSpecificInput" => {
      "token" => token}}
 
payment_request = CreatePaymentRequest.new_from_hash(payment_hash)
payment_response = merchant_client.payments().create_payment(payment_request)

Server-to-server

A minimum paymentResponse requires you to set at least an Order object and a payment method:

# Initialisation ...
include OnlinePayments::SDK::Domain
 
# Hash with all needed data for payment request
payment_hash = {
    "order" => {"amountOfMoney" => {"currencyCode" => "EUR", "amount" => 125000}},
    "cardPaymentMethodSpecificInput" => {
        "card" => {
            "cvv" => "123",
            "cardNumber" => "5300000000000006",
            "expiryDate" => "0124",
            "cardholderName" => "John Doe"},
        "paymentProductId" => 3}}
 
payment_request = CreatePaymentRequest.new_from_hash(payment_hash)
payment_response = merchant_client.payments().create_payment(payment_request)

Get transaction status

Our RESTful API allows you to request a transaction’s status anytime by one of our GET calls:

• GetHostedCheckout
• GetPaymentDetails
• GetCaptures
• GetRefunds

A GetPaymentDetails request looks like this:

response = merchant_client.payments().get_payment_details(payment_id)

For more information about statuses visit the status documentation page.

Perform maintenance operation

To perform follow-up actions on existing transactions (i.e. captures or refunds), use our CapturePayment or RefundPayment API call respectively:

CapturePayment

# Initialisation ...
include OnlinePayments::SDK::Domain
 
payment_id = payment_response.payment.id
capture_request = CapturePaymentRequest.new()
capture_request.from_hash({"amount" => 125000, "isFinal" => true})
merchant_client.payments().capture_payment(payment_id, capture_request)

RefundPayment

# Initialisation ...
include OnlinePayments::SDK::Domain
 
payment_id = payment_response.payment.id
refund_hash = {"amountOfMoney" => {"currencyCode" => "EUR", "amount" => 125000}}
refund_request = RefundRequest.new_from_hash(refund_hash)
# Get RefundResponse object
response = merchant_client.payments().refund_payment(payment_id, refund_request)

Handle exceptions

If a transaction is rejected, our platform provides detailed information with an Exception instance. The affiliated HTTP status code also help you troubleshoot the error.

You can encounter two types of exceptions: transaction exceptions and HTTP exceptions.

Transaction exceptions

This kind of exception refers to transaction requests that are technically correct but were rejected by your customer’s issuer or your acquirer. If the transaction is returned in the exception, it means that it was created in our systems but not successfully processed.

# Initialisation ...
include OnlinePayments::SDK::Domain
 
begin
    payment_response = merchant_client.payments().create_payment(payment_request)
    payment_id = payment_response.payment.id
rescue DeclinedPaymentException => e
    payment = e.create_payment_result.payment
    payment_id = payment.id
    payment_status = payment.status
    handle_error(payment)
end
 
payment_response = merchant_client.payments().get_payment(payment_id)
 
# Your code to check transaction status and handle errors. 
if is_not_successful(payment_response)
    handle_error(payment_response)
end 

# Initialisation ...
include OnlinePayments::SDK::Domain
 
payment_response = merchant_client.payments().create_payment(payment_request)
payment_id = payment_response.payment.id
 
refund_id = nil
begin
  refund_request = RefundRequest.new_from_hash(refund_hash)
  refund_response = merchant_client.payments().refund_payment(payment_id, refund_request)
  refund_id = refund_response.id
rescue DeclinedRefundException => e
  refund_result = e.refund_result
  handle_error(refund_result)
end
 
refund_response = merchant_client.payments().get_refunds(payment_id)
 
# Your code to check transaction status and handle errors. 
if is_not_successful(refund_response, refund_id)
    handle_error(refund_response)
end

HTTP exceptions

This kind of exception refers to various problems caused by technical errors in the API call or payment request.

You can combine any of the following code snippets with this standard CreatePayment request:

# Initialisation ...
include OnlinePayments::SDK::Domain
log = Logger.new(STDOUT)

# Hash with all needed data for payment request
payment_hash = {
    "order" => {"amountOfMoney" => {"currencyCode" => "EUR", "amount" => 124000}},
    "cardPaymentMethodSpecificInput" => {
        "card" => {
            "cvv" => "123",
            "cardNumber" => "5300000000000006",
            "expiryDate" => "0124",
            "cardholderName" => "Ruby Ruby"},
        "paymentProductId" => 3}}
 
payment_request = CreatePaymentRequest.new_from_hash(payment_hash)
begin
  payment_response = merchant_client.payments().create_payment(payment_request)
rescue ApiException => e
  # Refer to the list below to see how 
  # specific implementations of ApiException can be handled.
end

rescue ValidationException => e 
  log.error("Input validation error:") 
  e.errors.each do |error|
    if not error.property_name.nil?
      log.error("#{error.code}: #{error.message}")
    else
      log.error("#{error.property_name}: #{error.code}: #{error.message}")
    end
  end
end

rescue AuthorizationException => e
  log.error("Authorization error:") 
  e.errors.each do |error|
    log.error("#{error.code}: #{error.message}") 
  end 
end

rescue IdempotenceException => e
  log.error("Idempotence error:") 
    e.errors.each do |error|
      log.error("#{error.code}: #{error.message}")
    end
end

rescue ReferenceException => e
  log.error("Incorrect object reference:") 
    e.errors.each do |error| 
      log.error("#{error.code}: #{error.message}")
    end 
end

rescue ApiException => e 
  direct_er = e.errors.select{|error| [500, 502, 503].include? error.http_status_code}
  if not direct_er.empty? 
    log.error("Error occurred at Direct or a downstream partner/acquirer:")
    direct_er.each do |error|
      log.error("#{error.code}: #{error.message}")
    end
  end
end

rescue ApiException => e 
  log.error("Platform error: ") 
  e.errors.each do |error|  
    log.error("#{error.code}: #{error.message}") 
  end 
end

rescue CommunicationException => e
  log.error("Communication exception: #{e}")
end

HTTP status codes

All our exceptions are linked to one or more HTTP status codes, indicating the root cause for many possible errors.

Additional Features

The SDK has a lot more to offer. Have a look at the following features, as they will help you build the perfect solution.

• Get available payment methods
• Send idempotent requests
• Use logging
• Connection pooling
• Customise communication
• Webhooks

Get available payment methods

Before you initiate the actual payment process, you send a GetPaymentProducts request to our platform. The response contains a list of available payment methods in your PSPID. Depending on your customers’ preferences, you can offer a selection on our Hosted Checkout Page or on your own webshop environment using subsequent CreatePayment requests.

# Initialisation...
include OnlinePayments::SDK::Merchant::Products

product_params = GetPaymentProductParams.new
product_params.country_code = "FR"
product_params.currency_code = "EUR"

response = merchant_client.products().get_payment_products(product_params)

Response is an instance of GetPaymentsProductsResponse with a list of available payment products.

Send idempotent requests

One of the main REST API features is its ability to detect and prevent sending requests (i.e. payment requests) accidentally twice. The SDK makes it very easy for you to ensure that you send only unique – idempotent – requests to our platform.

Use the additional argument context and set its property named idempotence_key to a CreatePayment request. The SDK will send an X-GCS-Idempotence-Key header with the idempotence key as its value.

If you send requests this way to our platform, we will check the following:

• If you send subsequent request with the same idempotence key, the response contains an X-GCS-Idempotence-Request-Timestamp header. The SDK will set the idempotence_request_timestamp property of the CallContext argument.
• If the first request is not finished yet, the RESTful Server API returns a 409 status code. Then the SDK throws an IdempotenceException with the original idempotence key and the idempotence request timestamp.

# Initialisation ...

context = CallContext.new(idempotence_key="your_key_for_payment") 
payment_client = client.merchant_client(merchantId).payments()

begin
  payment_response = payment_client.create_payment(payment_request, context)
rescue IdempotenceException => e
  # A request with the same idempotence_key is still in progress, try again after a short pause
  # e.idempotence_request_timestamp contains the value of the
  # X-GCS-Idempotence-Request-Timestamp header
  log.info("Idempotent request: #{e.idempotence_request_timestamp}")
ensure
  idempotence_timestamp = context.idempotence_request_timestamp
  # idempotence_request_timestamp contains the value of the
  # X-GCS-Idempotence-Request-Timestamp header
  # if idempotence_timestamp is not empty, this was not the first request
end

Use logging

The SDK supports logging of requests, responses, and exceptions of the API communication. These can be helpful for troubleshooting or tracing individual steps in the payment flow.

To use this logging feature, you should implement the CommunicatorLogger class. The Ruby SDK provides two example implementations for logging to stdout (StdoutCommunicatorLogger) and logging to a logger (RubyCommunicatorLogger).

Have a look at a code sample presenting the case of adding a logger:

# Initialisation...
logger = RubyCommunicatorLogger.new(Logger.new('logfile.log'), Logger::INFO)
client.enable_logging(logger)
# Do some calls ...
client.disable_logging()

Connection pooling

You can manage your network resources by limiting the number of possible connections the SDK creates and maintains. The Client instances created as discussed in the Initialise SDK chapter will have their own connection pool. The Client instances created with the same Communicator object share a connection pool.

If you use multiple Client instances to share a single connection pool, make sure to follow these steps:

1. Create a shared Communicator . You can use the Factory class.
2. Create Client instances with that Communicator.

require 'onlinepayments/sdk'
include OnlinePayments::SDK
# Create shared communicator.
communicator = Factory.create_communicator_from_file(
    "payments_sdk.prp", apiKey, apiSecret
)
# Create one or more clients using the shared communicator.
client = Factory.create_client_from_communicator(communicator)

Customise communication

A Client uses a Communicator to communicate with our platform. Communicator implementations transform a request object to a HTTP request and a HTTP response to a response object. If needed, you can extend this class. To instantiate a Client that uses your own implementation of Communicator, you can use the following code snippet:

communicator = YourCommunicator()  
client = Factory.create_client_from_communicator(communicator)

However, for most customisations, you do not have to extend Communicator. The functionality of the Communicator is built on the following classes: Authenticator, Connection, Marshaller and MetaDataProvider, the implementation of which can easily be extended or replaced.

Marshaller is used to marshal and unmarshal request and response objects to and from JSON. We do not recommend changing this module. The other modules needed to communicate with the ANZ Worldline Payment Solutions platform are the following:

• Connection for one or more HTTP connections to our server.
• Authenticator to sign your requests.
• MetaDataProvider constructing the header with your server’s meta data.

For your convenience, the Factory.create_communicator_from_configuration and Factory.create_communicator_from_file methods can take optional arguments to set the Connection, Authenticator, Marshaller or MetaDataProvider modules. For example, the following code snippet allows you to use your own Communicator implementation:

connection = YourConnection.new
communicator = Factory.create_communicator_from_file(configuration_file_name,
                                           "api_key_id",
                                           "secret_api_key",
                                           connection: connection)
client = Factory.create_client_from_communicator(communicator)

Webhooks

The part of the SDK that handles the webhooks support is called the webhooks helper. It transparently handles both validation of signatures against the event bodies sent by the webhooks system (including finding the secret key for key IDs - not to be confused with the API Key and API Secret), and unmarshalling of these bodies to objects. This allows you to focus on the essentials, without going through all the additional information and extracting the desired ones by yourself. To learn more about webhooks, read our dedicated guide. 

Provide secret keys

Configure the "WebhooksKey" / "WebhooksKeySecret" and your server webhooks endpoints in the Merchant Portal:

key_id = "webhooks_key"
secret_key = "webhooks_key_secret"

Use InMemorySecretKeyStore to store a secret key for a key ID:

include OnlinePayments::SDK::Webhooks
key_store = InMemorySecretKeyStore.instance
key_store.store_secret_key(key_id, secret_key)

You can add or remove keys using the following functions:

• The key ID to return the secret key for
• A callback function that either takes an error as its first argument, or the secret key for the given key ID as its second argument (in which case the first argument must be null)

The SDK provides one implementation for this function: webhooks.inMemorySecretKeyStore.getSecretKey. This will retrieve secret keys from an in-memory key store.

You can add or remove keys using the following functions:

• key_store.get_secret_key(key_id) to get the stored secret key for a key ID.
• key_store.remove_secret_key(key_id) to remove the stored secret key for a key ID.
• key_store.clear() to remove all stored secret keys.

If you require more advanced storage, i.e. for a database or file system, we recommend writing your own implementation.

Initialise webhooks helper

Include and initialise the webhooks helper as follows:

helper = Webhooks.create_helper(key_store)

Use webhook helper

You can call a webhook helper to unmarshal incoming events which allows you to process data in your application. It takes the following arguments:

• The body as string. This should be the raw body as received from the webhooks system.
• A list with objects containing the request headers as received from the webhooks system. Each header object should have name and value methods returning header name and value respectively.

begin
  webhook_event = helper.unmarshal(body, headers)
rescue
  # Process an exception
end
# Process event