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.
Download solinor/paymenthighwayio
More information about solinor/paymenthighwayio
Files in solinor/paymenthighwayio
Package paymenthighwayio
Short Description Paymenthighway SDK
License MIT
Homepage https://paymenthighway.fi/dev/
Informations about the package paymenthighwayio
PaymentHighway PHP SDK
This library is being Deprecated, and won't get new features.
Requirements
- PHP 5.6.+
- Composer
Installation
add following to composer
Structure
\Solinor\PaymentHighway
Contains API methods. Use these to create Payment Highway API requests.
\Solinor\PaymentHihgway\Model
Contains Models used to inject paymentApi requests.
\Solinor\PaymentHihgway\Security
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
- The logo must be 250x250 pixel in .png format.
- MPO will show a default logo in the app if this is empty or the image location doesn’t exist.
- Once a ShopLogoURL has been sent to MPOnline the .png-file on that URL must never be changed. If the shop wants a new (or more than one) logo, a new ShopLogoURL must be used.
- The logo must be hosted on a HTTPS (secure) server.
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
ramsey/uuid Version ^3.0
nategood/httpful Version ^0.2
respect/validation Version ^1.0