zhutik / adyen-api-go Goto Github PK

Adyen provides a list of supported currencies with the number of decimal points to adjust.

F.e.:

• 15,60 EUR should be submitted as 1560
• 10 BHD as 10000

Docs and list of codes:
https://docs.adyen.com/developers/currency-codes

To refund captured transaction, add refund api call.

• Check Adyen API response and return correct structure
• Handle error cases as well

Adyen API Notifications support

• New structures for Notifications
• Process Adyen Notification

This call adds support for modification to already authorized (not yet captured) transaction

Adyen docs:
https://docs.adyen.com/developers/payment-modifications#adjustauthorisation

Add support for new 3D Secure 2.0

• add parameters to /authorise call and response
• add /authorise3ds2 request and response

Add credentials class support

Move API credentials logic into separate structure and update Adyen base class to process new credentials

Allow to submit card information to authorise payments

Currently, library supports only encrypted data, that comes from external JS file.

Hey mate,

Just reading through the page on live endpoints (https://docs.adyen.com/developers/api-reference/live-endpoints) and think we'll probably need to add in the [random] and [company name] parts into the live URLs...

I'm not sure whether the hpp/cse and hpp URLs need these parts, perhaps you know?

var Production = Environment{
	Name:      EnvironmentProduction,
	apiURL:    "https://%s-%s-pal-live.adyen.com/pal/servlet",
	clientURL: "https://%s-%s-live.adyen.com/hpp/cse/js/",
	hppURL:    "https://%s-%s-live.adyen.com/hpp/",
}

I propose we either add these as parameters to the ParseEnvironment function, or create a MakeEnvironment function, what do you think?

EUR is hardcoded right now, let Adyen be configured with currency setting.
Also, introduce default currency setting, so it will fallback to default, if configuration is not specified

Add support for checkout v41 API

Integrate:

• https://docs.adyen.com/api-explorer/#/PaymentSetupAndVerificationService/v41/payments
• https://docs.adyen.com/api-explorer/#/PaymentSetupAndVerificationService/v41/payments/details

From the Adyen docs, you can see that there are many different bits of information that can come back in a payment response: https://docs.adyen.com/developers/api-reference/payments-api#paymentresultadditionaldata.

In the AdditionalData of this library, there are only three assignable fields (because A) the input AdditionalData only supports a narrow subset of behaviour and B) the AdditionalData request struct is being reused for the response.

https://play.golang.org/p/SZKItF8r2ah

TL;DR: NewAmount needs to use math.Round(float64(amount * coef)) in order to ensure that it ends up with the closest whole minor unit, otherwise a truncation can occur and we drop a minor unit. Specifically, this happens with the value of 8.40.

In order to use errors in a defer statement (for closing etc.), the return parameter needs to be named.

Great work on this library, we are considering using it in our project and were wondering if there are plans to give support to the new API endpoint /payments to authorize payments?

Mainly, the benefit would come from payment methods that require a redirect workflow. iDeal, SOFORT, and such

Documentation of the new endpoint is here https://docs.adyen.com/api-explorer/#/PaymentSetupAndVerificationService/payments

Thanks again

Support of different API versions for payment and recurring

• For payment and modification API: v30 should be used
• For recurring API: v25 should be used

Hi guys,

first of all, thank you for building and maintaining this. It is awesome. We recently published the official go libs for the Adyen platform https://github.com/Adyen/adyen-go-api-library

Would you be willing to deprecate this lib in favor of the official ones?

Full disclosure: I work for Adyen as a dev advocate

Implement Adyen Directory Lookup request

In order to implement Adyen HPP (https://docs.adyen.com/developers/payments/accepting-payments/ecommerce-integration?ecommerce=ecommerce-integration#localpaymentmethods)
library need to be able to request selected payment methods based on skin, country and order details

Hello, ( and thanks for your work ! )

We need to add risk datas parameters to our request ( description available here : https://docs.adyen.com/developers/api-reference/payments-api/paymentrequest/paymentrequest-additionaldata )

For our use, we we would need:

• Two fields:
  • riskdata.shopperCountry and
  • riskdata.browserLanguage ( on a new struct RiskData ? )

and

• Params exposed on "Basket content fields" part:
  • riskdata.basket.item ( itemID, productTitle, amountPerItem etc .... )

I made a "quick dirty" test, mapping the fields like this on current "AdditionnalData" struct:

RiskDataItemProductTitle string json:"riskdata.basket.item.productTitle,omitempty"
RiskDataItemCategory string json:"riskdata.basket.item.category,omitempty"
RiskDataItemSize int json:"riskdata.basket.item.size,omitempty"

It seems to work as I see the information on Adyen backOffice,

But what I don't uderstand is how to map/generate "itemNr" required by adyen for each item, if you have any idea your help should be welcome to purpose a struct for our need,

Kind regards,
Thanks in advance,
JP

Remove Merchant Account and HPP configs from API initialization

To simplify library initialization, Merchant Account and HPP SkinCode need to be removed from the configuration and used only in specific requests.

Solution:

• MerchantAccount should be specified in request structures
• SkinCode should be specified in request structures
• ShopperLocale should be specified in request structures
• HMAC should be part of configuration as optional
• ClientID should be parameter for ClientURL method

Hello,

Would it be possible to add the "executeThreeD" element to the AdditionalData struct ? So that we may manually force the 3D secure authorisation process.

https://docs.adyen.com/developers/risk-management/3d-secure#authorisethe3dsecurepayment

Thank you :)

Currently, all Authorise, AuthoriseEncrypted and Authorise3D structures are used, but they are 95% identical.

AuthoriseEncrypted will be removed, "additionalData" field will be added to Authorise structure.
AuthoriseEncrypted method is Payment Gateway will be removed.
Authorise3D structure will be removed
Authorise3D method will be removed