PiA - Netaxept in-app SDK —-
Several reasons can lead to GENERIC_ERROR. Make sure to check the below:
transactionId
must be generated in the same environment as SDK (test/production)merchantId
and environment.TransactionInfo
object) the exact Redirect URLs that were used in the RegisterCall made by your Backend towards NetaxeptQuery
call from your backend towards Netaxept to get additional details on the issueIn Mobile SDK case, these redirect URLs are used to detect if a payment is successful or not. The user won’t be redirected a specific URL, but instead it will be returned back to the application with a PiaResult
object, where you will show your custom native confirmation page. The actual flow should be like this:
http://localhost/redirect.php
transactionId
and the same redirectUrl
back to your applicationtransactionId
along with the redirectUrl
received from your backend to the SDK in the TransactionInfo
objectIf you don’t provide the SDK the same redirectUrl that has been used in the registerCall, the payment authorization will be successful, but the result delivered to your application will be error - GENERIC_ERROR
.
The save card feature requires the amount to be set to 1 EURO (or one major currency amount: 1 DKK, 1 SEK, etc) and when payment/{transactionId}/storecard
endpoint is called, it will store the card and release the amount (the amount won’t be charged to the user).
The SDK errors originate from two sources:
These errors are always intended to developers, not to end-users as they are technical and do not always allow you to define the root cause and mitigating action.
When error messages are returned, we recommend to implement a merchant back-end call (Query API
) to get more details about the real issue.
We’ve provided a mapping table of error messages from Netaxept (check documentation) and our internal SDK error which will help Merchant to understand and handle the error accordingly in their manners.
The SDK currently supports: English
, Norwegian
, Danish
, Swedish
and Finnish
.
Default language setting is based on OS locale (language as defined in phone settings).
From version 1.2.0
, PiA SDK supports language customisation. Please refer to documentation on how to define the language at run-time.
The SDK supports all currencies available in Netaxept, so all major currency, following ISO 4217
standard. Make sure your acquiring agreement include the currency and use the relevant currency code when doing the REGISTER
call.
Error message:
*** Fetching Netaxept-iOS-SDK
*** Checking out Netaxept-iOS-SDK at "VERSION"
*** Skipped building Netaxept-iOS-SDK due to the error:
Dependency "Netaxept-iOS-SDK" has no shared framework schemes
This is just a warning. If you check the Carthage/Checkouts folder, you can find the Pia.framework
there. You don’t need to change/modify anything because this is the light-weight way of using Carthage. Refer to Carthage for more information
In order to be able to commit your changes, you need to add the Pia.framework
to your project’s .gitignore
file. For more information, go to ReadMe file.
Full error message: Unable to process application at this time due to the following error: Invalid Bundle. The asset catalog at ‘Payload/Arrow.app/Frameworks/Pia.framework/Assets.car’ can’t be processed. Rebuild your app, and all included extensions and frameworks, with the latest GM version of Xcode and resubmit.
Resolution:
In your project TARGET
, in the build phases, add new run script. If you want to avoid the error when running on simulator, please also check the box for this.
Note: Run script only when installing!
APP_PATH="${TARGET_BUILD_DIR}/${WRAPPER_NAME}"
# This script loops through the frameworks embedded in the application and
# removes unused architectures.
find "$APP_PATH" -name 'Pia.framework' -type d | while read -r FRAMEWORK
do
FRAMEWORK_EXECUTABLE_NAME=$(defaults read "$FRAMEWORK/Info.plist" CFBundleExecutable)
FRAMEWORK_EXECUTABLE_PATH="$FRAMEWORK/$FRAMEWORK_EXECUTABLE_NAME"
echo "Executable is $FRAMEWORK_EXECUTABLE_PATH"
EXTRACTED_ARCHS=()
for ARCH in $ARCHS
do
echo "Extracting $ARCH from $FRAMEWORK_EXECUTABLE_NAME"
lipo -extract "$ARCH" "$FRAMEWORK_EXECUTABLE_PATH" -o "$FRAMEWORK_EXECUTABLE_PATH-$ARCH"
EXTRACTED_ARCHS+=("$FRAMEWORK_EXECUTABLE_PATH-$ARCH")
done
echo "Merging extracted architectures: ${ARCHS}"
lipo -o "$FRAMEWORK_EXECUTABLE_PATH-merged" -create "${EXTRACTED_ARCHS[@]}"
rm "${EXTRACTED_ARCHS[@]}"
echo "Replacing original executable with thinned version"
rm "$FRAMEWORK_EXECUTABLE_PATH"
mv "$FRAMEWORK_EXECUTABLE_PATH-merged" "$FRAMEWORK_EXECUTABLE_PATH"
done
The customization of the PAY
button in the SDK is special as you also need to consider the drawable selector added to enable the pressed animation. There are two ways to provide customization for it:
GradientDrawable
object, specifying backgroundColor, border thickness, corners, etc.Example: Create an xml in /drawable
folder, named: pay_btn_selector.xml
<?xml version="1.0" encoding="utf-8"?>
<selector xmlns:android="http://schemas.android.com/apk/res/android">
<item android:drawable="@color/light_blue" android:state_pressed="true"/>
<item android:drawable="@color/custom_blue_color"/>
</selector>
Set the drawable through the API:
PiaInterfaceConfiguration.getInstance().setMainButtonBackgroundColor(ContextCompat.getDrawable(this, R.drawable.pay_btn_selector));
If your release APK is using the proguard to obfuscate the code and the minification is enabled, you need to add the following rules to your proguard-rules.pro
file:
-keep class eu.nets.pia.cardio.** { *; }
-dontwarn eu.nets.pia.cardio.**
These classes are located in the PiaSample
application, they are not part of the SDK. They suggest a way of integrating the SDK functionalities with the Sample Backend. You need to create your own flow based on your Backend Implementation.
No, the Netaxept SDK does not require pre-initialization for payments. However, as our documentation states, we suggest for best-practice to apply your UI Customization theme elements in the Application class, to have the SDK configured at run-time.
The SDK supports multiple card types (it detects the card type while user is typing, it shows the card logo and handles CVC/CVV/CID length and validation according to it).
However, the SDK does not decide if your Merchant Configuration (based on MerchantID) is allowed to make payments with that specific card. This is handled on the Netaxept side. To support multiple card types payments, you need to add Acquirer Agreements in Netaxept Admin Portal.
No! The SDK has no such functionality. Please refer to this question.
No, get card-holder name is not supported by Nordic issuers and PSPs.
As a PCI-DSS Level 1
payment service provider, Netaxept data handling is complient with industry policy. Shall you need additional information, please contact Netaxept customer support.
force3DSecure=true
):
force3DSecure=false
)
Indeed, you can define this fee in your backend and use it through the register call. However, you need to verify carefully when implementing this as it is regulated under PSD2. It is called surcharging and from the 1st of January 2018 a new directive from the EU does not allow for surcharging of private cards issued within the EU/EEA. This applies to transactions in both POS and E-com. The new directive doesn’t cover the following:
That means that it is still possible to surcharge for these card types.
You can define accepted card types during register call, using CardType
, CardOrigin
or CardProductType
. Please refer to Netaxept documentation.
To restrict accepted card type, activate relevant transaction filter(s) in Netaxept Admin portal.
Handle rejected cards in mobile SDK:
If a user wants to delete a card, just delete the panHash
from your database.
This depends on the type of the exception you encountered. The Query Call can provide you the details of the error and based on this you can chose if you will retry the request or not. But, Netaxept is done in such way that almost in any case the exceptions thrown are fatal, and there is no need for retry.