Download the PHP package solinor/paymenthighwayio without Composer

On this page you can find all versions of the php package solinor/paymenthighwayio. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.

FAQ

After the download, you have to make one include require_once('vendor/autoload.php');. After that you have to import the classes with use statements.

Example:
If you use only one package a project is not needed. But if you use more then one package, without a project it is not possible to import the classes with use statements.

In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
Some PHP packages are not free to download and because of that hosted in private repositories. In this case some credentials are needed to access such packages. Please use the auth.json textarea to insert credentials, if a package is coming from a private repository. You can look here for more information.

  • Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
  • To use Composer is sometimes complicated. Especially for beginners.
  • Composer needs much resources. Sometimes they are not available on a simple webspace.
  • If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
  • Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Please rate this library. Is it a good library?

Informations about the package paymenthighwayio

PaymentHighway PHP SDK

This library is being Deprecated, and won't get new features.

Requirements

Installation

add following to composer

Structure

Contains API methods. Use these to create Payment Highway API requests.

Contains Models used to inject paymentApi requests.

Contains classes used for hash calculations

Overview

Start with building the HTTP form parameters by using the FormParameterBuilder. Create an instance of the builder, then use the generate methods to receive a list of parameters for each API call.

Initializing the builder

Example generateAddCardParameters

For all Form objects returned by FormBuilder methods

Example generatePaymentParameters

Example generateGetAddCardAndPaymentParameters

Example generatePayWithMobilePayParameters with optional parameters

About shop logo in MobilePay

Example validateFormRedirect

PaymentApi

In order to do safe transactions, an execution model is used where the first call to /transaction acquires a financial transaction handle, later referred as “ID”, which ensures the transaction is executed exactly once. Afterwards it is possible to execute a debit transaction by using the received id handle. If the execution fails, the command can be repeated in order to confirm the transaction with the particular id has been processed. After executing the command, the status of the transaction can be checked by executing the PaymentAPI->statusTransaction( $transactionId ) request.

In order to be sure that a tokenized card is valid and is able to process payment transactions the corresponding tokenization id must be used to get the actual card token.

Remember to check the result code:

Code 100 means "Request successful". Other response codes can be found: https://paymenthighway.fi/dev/?php#rcode-result-codes

Initializing the Payment API

Example Commit Form Transaction

Example Tokenize (get the actual card token by using token id)

Example Init transaction

Example Debit with Token

NOTE: The debitTransaction method will be deprecated starting from Sep 14th 2019 in favor of the new chargeCustomerInitiatedTransaction and chargeMerchantInitiatedTransaction in order to comply with the EU's PSD2 directive.

Charging a card

After the introduction of the European PSD2 directive the electronic payment transactions are categorised in so called customer initiated transactions (CIT) and merchant initiated transactions (MIT).

Customer initiated transactions are scenarios where the customer takes actively part in the payment process either by providing their card information or selecting a previously stored payment method. Also so-called "one-click" purchases where the transaction uses a previously saved default payment method are CITs.

Merchant initated transactions are transactions which are initated by the merchant without customer's participation. Merchant initated transactions require a prior agreement between the customer and merchant also called the "mandate". Merchant initiated transactions can be used for example in scenarios where the final price is not known at the time of the purchase or the customer is not present when the charge is made.

Charging a customer initiated transaction (CIT)

When charging a customer initiated transaction there is always a possibility that the card issuer requires strong customer authentication. In case the issuer requests SCA then the response will contain "soft decline" code 400 and an URL where the customer needs to be redirected to perform authentication. The URLs where the customer will be redirected after completing authentication need to be defined in the ReturnUrls object.

In addition to the return urls the StrongCustomerAuthentication object has many optional fields for information about the customer and the transaction. This information is used in transaction risk analysis (TRA) and can increase the likelihood that the transaction is considered low risk so that strong customer authentication is not needed.

Charging a merchant initiated transaction (MIT)

When charging the customer's card in context where the customer is not actively participating in the transaction you should use the chargeMerchantInitiatedTransaction method. The MIT transactions are exempt from the strong customer authentication requirements of PSD2 so the request cannot be answered with "soft-decline" response (code 400) unlike customer initated transactions.

Example Revert

Example Transaction Status

Example Daily Batch Report

Example Order Status

Errors

Payment Highway API can raises exceptions and you should handle them in graceful manner.

Help us make it better

Please tell us how we can make the API better. If you have a specific feature request or if you found a bug, please use GitHub issues. Fork these docs and send a pull request with improvements.


All versions of paymenthighwayio with dependencies

PHP Build Version
Package Version
Requires php Version >=5.6.0
ramsey/uuid Version ^3.0
nategood/httpful Version ^0.2
respect/validation Version ^1.0
Composer command for our command line client (download client) This client runs in each environment. You don't need a specific PHP version etc. The first 20 API calls are free. Standard composer command

The package solinor/paymenthighwayio contains the following files

Loading the files please wait ....