B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S
B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S
B1 iPayment
1. iPayment general 7
1.1 iPayment and Payment Card Industry Data Security Standard (PCI-DSS) ..................... 8
1.2 GDPR Notes .......................................................................................................................... 9
1.3 iPayment and Payment Application Data Security Standard (PA-DSS) ....................... 10
1.4 PII/PCI ................................................................................................................................. 11
1.5 Data theft ........................................................................................................................... 11
1.6 Known limitations in iPayment ....................................................................................... 11
3. Gateway requirements 17
3.1 Secure Trading ................................................................................................................... 18
3.2 Authorize.NET .................................................................................................................... 18
3.3 CyberSource ....................................................................................................................... 19
3.3.1 Cybersource and interaction with Add credit card website [Mandatory] ................... 19
3.3.2 Cybersource and interaction with Add credit card [How does it work] ...................... 22
3.4 Eway ................................................................................................................................... 22
3.5 Moneris Canada ................................................................................................................. 22
3.6 Cayan .................................................................................................................................. 23
3.7 ProPay ................................................................................................................................ 23
3.8 Square ................................................................................................................................ 23
5. Setup 29
5.1 License ................................................................................................................................ 30
5.2 Database Information ....................................................................................................... 30
5.3 Configuration ..................................................................................................................... 31
6. Go-live checklist 59
6.1 Go-live ................................................................................................................................ 60
7. General use 63
7.1 Action log ........................................................................................................................... 64
7.2 Assign credit cards to customers ..................................................................................... 64
7.3 One-time Credit Cards/Customers ................................................................................... 67
7.3.1 Send one-time Credit Card link (Secure Trading only) ................................................ 69
7.4 Converting a One-Time Credit Card to a BP credit card ................................................ 70
7.5 Mass link generator .......................................................................................................... 71
7.6 B1 iPayment tab on documents ...................................................................................... 73
7.7 Automatic fraud check on authorization/settlement ................................................... 75
7.8 Authorization .................................................................................................................... 76
7.8.1 Void authorization ....................................................................................................... 78
7.8.2 Automatic re-authorization ......................................................................................... 78
7.9 Settlement window .......................................................................................................... 79
9. Troubleshooting 121
9.1 I get the error “-10 – Payment method not defined” when iPayment does
the settlement ................................................................................................................. 122
10.1 All open sales orders without a Credit Card record ..................................................... 124
1 iPayment general
Welcome to the B1 iPayment Manual. In it you will find all information on how to successfully use
the add-on. For installation and license, please see the separate Installation guide and license
guide.
Copyrights
Copyright© Boyum IT A/S 2005-2017. All rights reserved.
Warning: This computer program is protected by copyright law and international treaties.
Unauthorized production or distribution of this program, or any portion of it that is owned by
Boyum IT A/S, may result in severe civil and criminal penalties and will be prosecuted to the
maximum extent possible under the law.
SAP®, SAP Business One® and Crystal Report® are Registered Trademarks of SAP AG ® Corporation
MS .Net Framework®, MS Outlook®, MS Word®, Internet Explorer®, Windows® and Microsoft® are
Registered Trademarks of Microsoft ® Corporation
All trademarks and registered trademarks used in this documentation are property of their
respective owners.
When implementing iPayment please consult the PCI-DSS guidelines and understand the
conditions presented. iPayment is not PCI certified/validation as the certification process is
required to be completed by merchant and not Boyum It A/S. The bottom line is that only an
organization/merchant can be validated to be PCI-DSS compliant, never an application or a
system[1]. It is up to the merchant to make sure that all the conditions for PCI compliance or PCI
certification depending on the route taken is fulfilled when implementing iPayment. As
iPayment uses tokenization this reduces the PCI-DSS scope required to be completed by the
merchant but it does not remove it entirely. Please see the tokenization chapter to learn more
about how iPayment works with tokens.
Boyum It A/S cannot help with the PCI-DSS certification or PCI-DSS compliance as we are not a
Qualified Security Assessor (QSA). We also cannot assist in picking the correct Self -Assessment
Questionnaires (SAQ) as this depends on the setup of your business. Please contact your local
QSA partner or gateway to get assistance on this. We are able to assist on answering technical
questions on how iPayment operates if required by the QSA partner.
The General Data Protection Regulation (GDPR) is a regulation by which the European Parliament, the
Council of the European Union, and the European Commission intend to strengthen and unify data
protection for all individuals within the European Union (EU). It also addresses the export of personal
data outside the EU.
The GDPR aims primarily to give control back to citizens and residents over their personal data and to
simplify the regulatory environment for international business by unifying the regulation within the EU.
It is to the best of Boyum IT Solutions A/S ability that B1 iPayment adhere to privacy by design as the
add-on does not store any personal data beyond the SAP Business One database itself but below are
references to how B1 iPayment handles data
General
All configured data are stored in the SAP Business One database itself and will not leave the customers
system. It is the people responsible for the SAP Business One environment that ensure these data are
kept secure.
License System
Our online license check will at start-up of the add-on communicate with https://portal.boyum-it.com/
LicenseKey. During this call, we send the following information in order to verify you have a valid license
•Installation + System Number
•DB Name,
•Number of SAP Users and assigned iPayment users
•Database server name
It is possible to block this call (via normal firewall) and work with an offline license key, without
interruption
Feedback System
The add-on has an optional Feedback system that on add-on shutdown and in case of errors send
anonymous data to Boyum's internal Feedback servers. It sends the following data to us:
•Install no
•SAP Version
•.NET Version
•OS Version
•SAP Username
•SAP Dabasename
•Stats for each module (number of configurations etc. - nothing customer specific)
You choose on initial install if you want to participate or not and can at any time turn it off.
All of the collected data can be deleted upon request.
More information about the Feedback System can be seen here: http://www.boyum-it.com/sbo/uip
Cloud connector
The add-on uses a Cloud Connector located in the Microsoft Azure hosting environment to facilitate easy
of use for some of the features we offer.
The Cloud Connector does not store any sensitive or user-specific data at any point.
PCI PA-DSS is the standard against which Payment Applications needs to be tested, assessed, and
validated. PCI-DSS Compliance is later obtained by the merchant. Obtaining PCI-DSS Compliance
is the responsibility of the merchant. As much as the PA-DSS provides industry standards for
developing payment applications, not all software applications that play a role in transactions are
eligible for review and listing by the PCI SSC under the PA-DSS program. iPayment does not fall
under the category of a Payment Application and we are not eligible for PA-DSS validation as we
do not store, process or transmit cardholder data as part of authorization or settlement. In regards
to cardholder data PCI-DSS, does not apply if PANs are not stored, processed, or transmitted[2] by
the payment application. This is the case with iPayment that never store, process or transmit
PANs.
The PCI Security Standard Council has created the following document https://
www.pcisecuritystandards.org/documents/which_applications_eligible_for_pa-
dss_validation.pdf on how to determine if an application like iPayment is eligible for PA-DSS
validation. The document has the following sentence: “If the answer is YES to ANY of the
following questions, the application is NOT eligible for validation under PA-DSS.”.
The answer for iPayment is yes to point 3: “Does the application facilitate authorization or
settlement, but has no access to cardholder data or sensitive authentication data?” and iPayment
is not eligible for review.
What should a merchant or service provider do if they use, or wish to use, applications that
store, process or transmit cardholder data that are not eligible for PA-DSS validation?
Applications that store, process or transmit cardholder data and that are not eligible for PA-
DSS validation would be included as part of an entity’s annual PCI DSS assessment to ensure
that the application is compliant with all applicable PCI DSS requirements.[3]
What should an application vendor do if their product is not eligible for validation under
the PCI SSC’s PA-DSS Program?
If an application is not eligible for validation under the PCI SSC’s PA-DSS program, the PCI
SSC recommends that those applications, if intended for use in the cardholder data
environment, are developed using PA-DSS as a baseline for protection of payment card
data. Merchants and service providers using or wishing to use such applications in their
cardholder data environment would include these applications as part of their annual PCI
DSS assessment.[4]
We have developed iPayment using PA-DSS as a baseline but iPayment are not eligible for
validation.
1.4 PII/PCI
Does B1- iPayment transmit PII or PCI data from/to the ERP host system?
Only non-sensitive PII data like first name, last name, street, city, state, country, email and postal
code are transmitted. Only non-sensitive PCI data is transmitted like masked Credit Card number,
expiry data and Credit Card type.
What is the transmission method and is the data encrypted?
The transmission is done using a HTTPS call to the gateway API. PCI sensitive data like full Credit
Card Number and Security Code are never transmitted or stored in the database.
CyberSource specific
The transmission is done using a HTTPS call to the CyberSource gateway API. Besides being
transferred using HTTPS the data is also encrypted using a private certificate that is created by
CyberSource (https://www.cybersource.com/developers/getting_started/test_and_manage/
update_keys_and_certificates/) and the certificate is then used by CyberSource to verify that
sender.
In case of data theft change the username/password/transaction key for the gateway login.
The Credit Card tokens in the database are useless to any attacker as it does not contain any
payment information.
The gateway login information is encrypted in the database but given enough time it might be
possible to reverse the encryption so we advise changing the login details on data theft.
· Business Partners
o “All Currencies” Business Partners are not supported as the token is only valid for
one specific currency.
[5]
[1] These data elements must be protected if stored in conjunction with the PAN. This protection should be per PCI DSS
requirements for general protection of the cardholder data environment. Additionally, other legislation (e.g., related to
consumer personal data protection, privacy, identity theft, or data security) may require specific protection of this data,
or proper disclosure of a company’s practices if consumerrelated personal data is being collected during the course of
business. PCI DSS, however, does not apply if PANs are not stored, processed, or transmitted.
[2] Sensitive authentication data must not be stored after authorization (even if encrypted).
[3] Full track data from the magnetic stripe, magnetic stripe image on the chip, or elsewhere.[6]
iPayment does not store primary account number (PAN), Full Magnetic Stripte Data, CAV2/CVC2/
CVV2/CID or PIN/PIN block. As we do not store the primary account number we are not we are not
required to protect the cardholder name, service code or expiration date.
All interaction with the gateways are done using a Card store/Customer Information Manager
system.
This means that only a token generated by the gateway is stored in the system but not the actual
primary account number.
Authorize.NET http://developer.authorize.net/api/reference/features/
customer_profiles.html
Secure Trading http://www.securetrading.com/service/card-store-
tokenisation/
CyberSource https://www.cybersource.com/products/payment_security/
payment_tokenization/
Eway https://www.eway.com.au/developers/api/token-
payments
You can read more about data tokenization here:
https://en.wikipedia.org/wiki/Tokenization_(data_security)
Tokenization can be defined as “the process of substituting a sensitive data element with a non-
sensitive equivalent, referred to as a token that has no extrinsic or exploitable meaning or
value”[7]. Tokenization is not a new or purely technical term as it has origins dating back
thousands of years. During the course of time when someone has had the need to protect a
currency or a valuable item during a transaction, they have used tokenization by switching it with
a less-valuable item. A good example of tokenization happening today is the use of casino chips
where real money are switched for a token.
When dealing with Credit Cards in a business environment there is a constant threat of cyber-
attacks that has made business extremely susceptible to exploitation. Losing a SAP Business One
database that contains Credit Card information is the worst case scenario for many businesses as
this can ultimately lead to having your customers Credit Card information exploited by criminals.
Tokenization as utilized by major payment gateways digitally converts sensitive data to a token
that has no value outside a specific gateway system. When a gateway provides a tokenization
service, the gateway system must be secured and validated using security best practices
applicable to sensitive Credit Card data protection, secure storage, audit, authentication and
authorization. This is all handled by the gateway lowering the security requirements for
businesses that uses the tokenization service. For this reason, tokenization provides excellent
security to data that is stored in a system.
Tokenization vs Encryption
A common misconception is that tokenization and encryption are essentially the same. In fact,
tokenization and encryption are very different in how they protect data.
Encryption is the process of taking data and encrypting it into an unreadable format. While
encryption does provide a substantial layer of protection against unauthorized viewing of data,
the data needs to be decryptable so that it can be returned to the original format. This is indeed
the case with solutions that encrypt Credit Card data in the database as they need to be able to
reverse the encryption and extract the Credit Card number when processing transactions. If you
have the correct key, you are able to decrypt the data and reveal the Credit Card numbers. This
weakness has led hackers to develop sophisticated programs that have ultimately succeeded in
untangling encrypted data previously considered unbreakable.
Tokenization instead replaces sensitive payment data with a token that cannot be mathematically
reversed back to the original data.
How does iPayment use tokenization?
When gateway tokenization is utilized in combination with B1 iPayment, it provides substantial
protection to customers and businesses alike. Should a data breach occur the database would
only be yielding unusable tokens to hackers. The tokens cannot be reversed to the actual Credit
Card number and is as such useless for the fraudsters.
The result of this process is that only a token generated by the gateway is stored in the SAP
Business One database but not the actual primary account number. This leads to increased
security as no one is able to obtain the primary account number after it has been submitted to the
gateway. iPayment uses the token to keep track of the transaction and handle authorization,
settlement and refunds.
A token is unique for a gateway and an account and as an example a token from Authorize.NET
cannot be used with Secure Trading/CyberSource or even a different account at the same
gateway. This renders the token entirely useless for anyone who is able to obtain it as it cannot
be reversed to the actual Credit Card number and the token is linked to the account at the
gateway.
Question and answers for tokenization
Does iPayment store Credit Card data in the database?
a. Yes and no. It stores the token that represents the primary account number but not
the primary account number itself. The following are stored by iPayment:
i. The token that represents the primary account number. As explained above
this cannot be reversed to the actual Credit Card number.
ii. Expiry data of the Credit Card
iii. Credit Card type
iv. A masked version of the primary account number provided by the gateway.
This cannot be unmasked and you cannot get access to the full primary
account number. iPayment cannot unmask the primary account number and it
will show like on a paper receipt from a store - XXXX0027.
v. The information on the Credit Card like Firstname, Lastname, city, country etc.
for fraud checking.
b. iPayment does NOT store the following:
i. Security Code (CVV, CAV2, CVC2, CVV2, CID)
ii. Primary account number
2. How/where are the Credit Card data stored?
a. The token and the connected data is stored in a User Defined Table in the database
([@BOY_E0_CREDITCAEX]). You as a customer should maintain strict security rules and
use best practice for storing sensitive data as following the guidelines by the PCI-DSS
scope. Tokenization does not remove the requirement but it help prevent leaking
primary account number if a breach happens.
3. How long do the tokens last
a. Until the deleted from the system or the Credit Card expires.
4. Is there a way that the customer can enter their Credit Card info without an employee seeing
the info?
a. If you use Secure Trading as the gateway then yes. With Secure Trading as the
gateway we have the option to send out a link created by Secure Trading that allows
the customer to enter the Credit Card information in a secure environment provided
by Secure Trading. After entering the Credit Card information the token will be
connected to the Business Partner in SAP where the link was generated from and can
then be used to process payments without any employee or iPayment having access
to the full Credit Card data.
We do not have this option for the other gateways as Secure Trading are the only one
to offer this solution right now.
3 Gateway requirements
Please carefully read and understand the documentation provided by the gateway. Acquiring
banks and gateways may have special rules around authorization length, fraud check and refunds
that will affect your overall fee level. Additional fees or fines may be imposed if you fail to
adhere to the rules.
For full terms and conditions, please contact your gateway or acquiring bank.
The server component should be installed on the server after installing and running the add-on in
each database that should be used.
Please see the separate “B1 iPayment server component installation guide.pdf” file.
3.2 Authorize.NET
3.3 CyberSource
3.3.1 Cybersource and interaction with Add credit card website [Mandatory]
To comply with PA-DSS requirements iPayment is not allowed to transfer credit card details from
SAP Client to gateway. For that reason it need to be done on a website controlled by CyberSource
that you open from within the SAP Client.
Setup needed for this to work
· Login to Cybersource gateway as administrator
o Navigate to Tools & Settings > Secure Acceptance > Profiles
o Press Create new profile
o Input name (example iPayment CreditCard)
o Select Itegration method ‘Web/Mobile’
o Input Company Name
o Enable ‘Payment Tokenization’ under added value services
o
o Press Create (you will be navigate to the new profile)
· On the profile page press “Notifications”
o Enable ‘Merchant POST URL’ and write https://ipayment.boyum-it.com/
CyberSource/ProcessNotification in the field
o Enable ‘Merchant POST Email’ and write your e-mail to notifications on (once
everything is working you can optionally disable this again)
o
o Save and return to the Profile overview
· On the profile page press “Payment Settings”
o Here you need to setup the payment method available on the add credit card
webpage and save.
· On the profile page press “Security”
o Press the ‘Create new key button’
o Give the key a name and press ‘Generate Key’
o Save the Access key and Secret Key as they need to be inserted into the iPayment
configuration
o Return to profile home
§ The fields are made mandatory by CyberSource and it will not work if they
are not marked as mandatory
§ Press “Save”
· Add profile id to the iPayment configuration:
o At the top of the profile home page there is a Profile ID. This is the last piece of
information you need to add to the iPayment configuration along with the Access
key and Secret Key found under security.
o
· Promote the configuration to “Active” using the “Promote to Active” button on the
profile home page
· If you are running on a live environment, you will need to contact CyberSource support
to have the profile published to the live servers.
· After having the profile published you can now add a Credit Card in iPayment.
3.3.2 Cybersource and interaction with Add credit card [How does it work]
After completing, the setup as explained above you should now be able to add Credit Cards to
customers using a webpage. This works in the following way:
1. iPayment contacts CyberSource and asks for a URL
2. A webpage is launched in your browser
3. You enter the customers details in a secure website provided by CyberSource
4. CyberSource makes a callback to the URL specified in the “Merchant POST URL” and the
token for the Credit Card is saved
5. iPayment contacts the URL specified in the “Merchant POST URL” and saves the token for
later use.
As CyberSource requires a callback server to exist, we have opted to provide a server
(ipayment.boyum-it.com) that allows for easy setup of the system.
The following fields are saved when the callback happens from CyberSource:
· Credit Card token
· Profile ID
· iPayment reference
· Timestamp
· AVS/CVV fraud check result codes
The data is deleted when iPayment requests the token from ipayment.boyum-it.com. The data is
also anonymous as Boyum It cannot identify the origin of the data as only you know the profile ID.
The token is unusable for anyone but you as it is linked directly to your CyberSource account.
3.4 Eway
o Hosted Tokenization must be set up in your Moneris Canada account - this allows
you to obtain a Hosted Tokenization Id, that is required to configure iPayment.
3.6 Cayan
3.7 ProPay
3.8 Square
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
Pre-Authorisations and Final Authorisations MasterCard Europe Mandate
Please carefully read the 11.1 topic in the file: http://www.securetrading.com/files/
documentation/STPP-XML-Specification.pdf.
You will need to decide if you want to use PRE or FINAL authorization for MasterCard and you
need to consider the implications of doing so. Failing to do so may result in a fine from
MasterCard.
4.2 Authorize.NET
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
4.3 CyberSource
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
Testing
While testing with CyberSource please note that the amount is required to be specific values. If
the amount is not the correct value the test api will reject the transaction.
For an overview of amounts please see: http://www.cybersource.com/developers/
getting_started/test_and_manage/simple_order_api/HTML/Paymentech/soapi_ptech_err.html
and http://www.cybersource.com/developers/getting_started/test_and_manage/
legacy_scmp_api/
Amount values that will be accepted: 164, 2100, 2101, 2102, 2103, 2014, 2015, 2106, 2107, 2108,
2109, 2110, 2111.
Any values outside of the above will return a general error: “General decline of the card. No other
information provided by the issuing bank.”
4.4 Eway
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
Pre-auth
Pre-auth is currently only available to Australian, Singapore, Malaysian & Hong Kong merchants
Batch refunds and outgoing payments
Please note that Eway does NOT support batch refunds and outgoing payments not tied to a
transaction previously made using the gateway.
This is due to the fact that Eway can only handle refunds for previous transactions made through
them, thus they do not support refunding a specified amount to a customer with no relation to a
transaction.
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
4.6 Cayan
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
4.7 ProPay
CVV codes
The CVV codes are send in on the first Credit Card add request and as it is not stored by iPayment
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
store the CVV code so any additional request will not have the CVV code checked.
5 Setup
5.1 License
Once the add-on is installed and started go to Administration -> Add-Ons -> B1 iPayment ->
License Administration and assign the users that needs to use the add-on functionality.
Click Database Information then type in a user that has read/write access to the database. Use
“Test connection” button to review if the information is correct.
5.3 Configuration
Click the Configuration menu item and select the gateway that you would like to use.
Fill out the details for the gateway or enable demo mode for testing.
Customers needs to have a specific currency set. You cannot use the "Multi-currency" customer.
When going live you will need to confirm that you have done all needed setups before going live
(in demo mode you can leave the tasks unchecked). The different gateways have different go-live
steps but here is an example of the Authorize.NET go-live checklist
For each step you can press the Golden arrow to get more information about the Task or be taken
to where you make the change.
IMPORTANT: It is your responsibility that a step is done correctly. The gateways do not have APIs
for iPayment to check if task if truly done or not.
5.3.1 Secure trading
Site security Enter a shared site security key (this key must be send to
Secure Trading support along with the site reference)
Parameters are:
1. currency
2. mainamount
3. sitereference
4. orderreference
5. credentialsonfile (optional)
6. PASSWORD
5.3.2 Authorize.NET
5.3.3 CyberSource
Live transactions Check to connect to the live API. If this is not checked you will connect to
the sandbox API.
Demo mode If you enable this option you will use a test account with CyberSource. All
transactions will be in test mode and you will be able to test the product
without having a CyberSource account. You can do settlements, refund
etc. in a secure demo environment.
5.3.4 Eway
API Key Enter the Eway API Key (My Account à API Key)
API Password Enter the Eway API Password (My Account à API Key)
Demo mode If you enable this option you will use a test account with
Eway. All transactions will be in test mode and you will be
5.3.6 Cayan
5.3.7 ProPay
Auth token Auth Token provided by ProPay when you sign up for an
account.
Biller Account Id Biller Account Id is provided by ProPay when you sign up
for an account.
Merchant Profile Id Merchant Profile Id is provided by ProPay when you sign
up for an account.
5.3.8 Square
Merchant Id The merchant Id for your account. You can find this in your
account page after signing up for a Square account.
Authorize iPayment This button will allow you to sign in using your Square
credentials, to authorize the iPayment application to
perform the transactions it needs to.
5.3.9 General
Integrations
B1P&D should handle Enabling this option will hide some functionality surrounding copying
one-time Credit Card links for one-time Credit Card documents. iPayment will assume that
links B1P&D will handle the delivery of the links using email.
Please see the B1P&D manual for information on how to setup this
feature.
Note: Enabling this option will not automatically make B1P&D send out
email links. You will need to configure B1P&D and use the iPayment
specific keywords.
record when for the Credit Card will be saved to the Business Partner and can then be
importing transactions used to process future transactions.
Authorize.NET
integration
Currency Authorize.NET only:
(Authorize.NET only) The currency selected needs to match the currency that your
Authorize.NET account was created in. Authorize.NET does not support
changing currencies through the API so it is important that you get the
account created in the correct currency.
Authorize.NET
Requires ECC (Extended Credit Capabilities) to be enabled
Require CVV/CVV2 Enabling this option makes the Security Code (CVV) field on the “Add
(Security code) Credit Card” form mandatory.
CIM: Do Authorization Authorize.NET only:
on credit card add If you turn this off Authorize.NET will not do an automated 0.00$
(fraud check) Authorization check when adding credit-cards via the webpage.
(Authorize.NET only)
Use internal browser If enabled adding new Credit Cards will be done using a browser window
inside SAP
Store Credit Card If enabled all personal data on the credit card is stored locally and visible
Display Information in the Credit Card window. This data is never used except to display in the
Credit Card window.
You can learn more about this in the Secure Trading documentation in
section 1.4 - Credentials on File (CoF):
https://www.securetrading.com//files/documentation/STPP-Payment-
Pages-Setup-Guide-V2.pdf
Note: Enabling this options means you'll have to contact Secure Trading to
have it included in your Site Security fields. See Configuration-->Secure
Trading for more details.
Auth Method Secure Trading only:
(Secure Trading only) Auth methods are used to specify how a transaction is to be processed by
the card issuer
If set to Final, iPayment make all calls using the 'Final' Method. Read more
about the Auth method via the More info link
5.3.10 Authorization
Authorization
Sales Order Select which authorization type you want to use.
If you uncheck the checkbox the authorization options will
not be available for this document.
Delivery Select which authorization type you want to use.
If you uncheck the checkbox the authorization options will
not be available for this document.
A/R Down Payment Invoice Select which authorization type you want to use.
If you uncheck the checkbox the authorization options will
not be available for this document.
A/R Invoice Select which authorization type you want to use.
If you uncheck the checkbox the authorization options will
not be available for this document.
A/R Reserve Invoice Select which authorization type you want to use.
If you uncheck the checkbox the authorization options will
not be available for this document.
Additional authorization options
Payment Terms Level BP Level:
Document Level:
Uses the Payment Terms on the Document to determine
which Payment Terms Configuration to use.
Control sales order approval If this option is enabled iPayment will set “Approved” as
false on “Sales Orders” that uses Credit Cards. It will
update the “Approved” field to true when an
authorization has been completed.
If you void the “Authorization” then “Approved” flag will
be set back to false.
Automatic settlement
A/R Down Payment Invoice Enable this option if you want the system to automatically
settle when adding the document.
All authorization logic will be disabled on the document if
this is enabled.
A/R Invoice Enable this option if you want the system to automatically
settle when adding the document.
All authorization logic will be disabled on the document if
this is enabled.
This means the user won't have to manually edit each line
when batch settling.
Reauthorize when performing partial Enabling this option will tell iPayment to reauthorize the
settlements remainder of the existing authorization when doing partial
settlements.
Create incoming payments while Enable this option to create incoming payments when the
doing settlements settlement is created.
Note: If you enable this option you need to use the “Credit
Card Mapping” button below!
Outgoing payments
Refund using This option determines what kind of documents there will
be created when making batch refunds or non-linked
refunds from at credit memo. the option is
· No document
· Outgoing payment
· Negative incoming payment
Outgoing payments account Enter/select the account to be used for the outgoing
payment.
Ramtool
Payment account Secure trading only:
Enter/select the account to be used for the incoming
payment that will be created during the settlement
process/when importing files from Ramtool
Fee account Secure trading only:
Enter/select the account to be used when posting Secure
Trading/Credit Card fee. The fee will be taken from the
payment account and moved to the fee account using a
journal entry.
Ramtool folder Secure trading only:
If you want to use Ramtool for reconciliation you need to
select a folder where you download the files to. You can
read more about this feature in the “Ramtool” section.
In the Credit Card mapping window you need to map the gateway Credit Cards to the SAP Credit
Cards. This is required if you use the incoming payment functionality.
You can specify a default card that will be used if no other matches are found.
Note: If this is not setup correctly iPayment will not be able to create incoming payments.
5.3.13 Permissions
Permissions
Right-click refund users (Empty = ALL) This controls what users should have access to the right-
click refund option on the A/R invoice documents. If the
field is empty, all users can access the right-click options.
5.3.14 Alerts
Here you can setup users that should receive an internal message if something happens while
working with the gateway.
Example:
Settlement could not be completed
Authorization could not be completed
Missing default credit card in combination with automatic settlement
If you toggle the 'Exclude from Batch Wizards' option, documents using the configured payment
terms will not be included in any of the batch filter screens.
You can remove the configuration by using the “Remove” button (Will only show after the
configuration is added).
The payment terms level can be configured on the configuration screen. Please refer to
Settlement and Refund page of the configuration screen.
You can change the Javascript and css to include your company logo and change titles/text strings
by modifying the files.
Note: Please consult the Secure Trading documentation for information on how to do this.
Important: Boyum IT A/S does not offer support on customizing the pages. Please contact the
Secure Trading support for help.
Here the International Code column needs to match a Secure Trading currency code provided in
the link above.
Scenario:
1. A order is created for 4000 EUR with an authorization on 4000 EUR
2. This order is copied into multiple delivers during a short period of time
3. Each delivery is after having been created copied into an invoice document
4. The invoice document is settled using iPayment as you want to pull the money for the partial
shipment when the delivery is made
The issue arrives as iPayment will use the initial authorization on the order to settle the first
invoice (can only be used once).
This will mark the authorization as settled even if you only settle a small amount of the initial
authorization.
Example:
Sales order is 4000 EUR
Invoice is 1000 EUR
iPayment will settle the first invoice using the 4000EUR authorization (but will off cause only draw
1000 EUR).
The next time you create a delivery and invoice you settle an additional 1000 EUR. This will create
a new settlement without a reference to the 4000EUR authorization as this has already been used
to settle the first invoice.
At some point in the future you create the last delivery for the remaining amount (2000 EUR) and
invoice this.
Flow:
The issue that might be is that the customer’s account does not have the funds needed to
complete invoice 2 and 3 as the 4000EUR is still reserved by the original authorization (normally 7-
10 days) despite that is has already been settled.
Technically a authorization cannot be re-used when it has been settled and even after doing the
settlement some of the funds will still be held until the funding for the settlement completes.
Due to the above we do not recommend authorizing large amounts at the Sales Order level if you
are going to use split shipments as you may then start getting your transactions rejected when
processing the invoice.
Please see the child chapter to identify the alternative work-flow suitable for your business. 56
With the above limitations in mind we have decided to not implement gateway specific logic as
the main merchant bank (Secure Trading Financial Services) does not support this and it would be
limited to specific card types.
Other gateways (Authorize.NET/CyberSource etc.) does not have any specific logic for handling
split shipments and instead recommend creating a suitable work-flow [Link].
An alternative is to only authorize the amount expected in the first shipment on the Sales Order.
This way you will get some security without reserving more funds than required to process the
first delivery. This is a manual process and the person creating the sales order need to know what
the expected first shipment amount will be.
Note: It is important that the A/R Invoice amount is the same or less than the Delivery as
otherwise iPayment will need to create a new settlement as the authorization cannot be used.
This would lead to the same issues as outlined in the "Handling large authorizations and split
shipments" chapter.
This way you will use the authorization from the Sales Order to settle the A/R Invoice leading to
only settling one transaction instead of multiple.
This can be achieved using the Copy from functionality in SAP where you settle all the Deliveries
that is created from the Sales Order.
It is important that the A/R Invoice amount is the same or less than the Sales Order as otherwise
iPayment will need to create a new settlement as the authorization cannot be used. This would
lead to the same issues as outlined in the "Handling large authorizations and split shipments"
chapter.
In the Credit Card Payment Methods you have the option to specify "Payments" as a column.
We do not support any options other than "No". iPayment does not support installment
payments.
6 Go-live checklist
6.1 Go-live
Before go-live please make sure that you have read and completed all the steps below.
We recommend printing this page and keeping it for reference after go-live.
Skipping any of the steps outlined below may lead to errors and delayed support cases.
1) General
· We recommend always using a sandbox database for testing of iPayment
· Note: Once you switch from Demo-mode to Live-Mode, all iPayment tables will be cleared, and
the action can't be reversed.
· Read "General must read notes on gateways" for the gateway you are implementing
· Read "Handling large authorizations and split shipments" 54 and decided if this applies to the
customer or not
· Read "Known limitations in iPayment" 11
· Read "iPayment and Payment Card Industry Data Security Standard (PCI-DSS)" 8 + "iPayment
and Payment Application Data Security Standard (PA-DSS)" 10
· Read "Data theft" 11
Note: Not getting all gateway features enabled (example CFT) may not give errors immediately
but it will give issues later on when doing a refund.
Customers needs to have a specific currency set. You cannot use the "Multi-currency" customer.
The users that are going to use iPayment should receive appropriate training and should all know
where to obtain the iPayment manual.
They should be instructed in how to handle Credit Card details securely and in compliance with
PCI-DSS.
5) Testing
We test each iPayment version released with a number of automated and manual test cases but it
is your responsibility to test that the product behaves as expected before go-live.
We recommend that you to run a few small value test transactions with real cards before starting
to accept customer orders.
· Test your work-flow and create a new order and test authorizations
· Create invoice documents and settle the invoice
· Issue a partial refund
· Issue a full refund
· Test the incoming/outgoing payment functionality
Check using the gateway backend that all transactions are processed as expected and have the
correct amounts
6) Make sure to show and instruct the super-users in how the "Action log" 64 window works
The action log is a very important tool as it contains a log of everything done with iPayment and
who did it.
This tool is both an audit and a support tool to show you what has happened in the system.
When requesting support we may ask for information from the action log to be included in the
ticket.
Post go-live
After go-live it is important that new versions released of iPayment are checked for bugs relating
to functionality that the customer are using and that new versions are installed if any corrections
have been made.
You can find the version history at: https://ipayment.boyum-it.com
1) Requesting support
Before requesting support please read this article on what information should be included
7 General use
After the add-on has been successfully installed, configured and started the users can start to
assign credit cards to customer, create, authorize and settle documents and so on.
The iPayment action log allows you to view all user and system actions done in iPayment.
The log can be accessed from Administration -> Add-ons -> B1 iPayment -> iPayment action log
It contains different columns that can help in identifying the user, amount, action done etc.
You have the option to filter the data and lookup data for a specific user or action.
7.2 Assign credit cards to customers
Find a relevant customer in the system and go to the “Payment Terms” tab, click the button
“Credit Cards“ and a new window will open showing all credit cards assigned to the customer.
If you want Credit Card payments to be enabled for the customer please check the checkbox “Use
Credit Card as payment option for this business partner”.
Note: The first credit card that is added will always be marked as default.
Default column The default Credit Card will be used and suggested automatically in
windows and automatic actions.
The card name column is an information only column. You are free to
Card name column
change the name to something different. The card name will be shown in
the Authorization window and other windows in the system.
You have the option to link the Credit Card to a specific contact person. If a
Contact Person
Contact Person is selected the Credit Card for that Contact Person will be
column
used when doing automatic actions on documents where the Contact
Person is selected.
Max. amount pr. Here you can define the maximum amount that can be authorized/settled
trans. pr. transaction for a card.
This will influence the authorizations and the settlements. If a doc total for
an invoice is higher than the maximum amount it will only settle what it
can.
Clicking button “Add” on the right side of this window will, depending on the configuration,
either open a browser or a window in SAP.
When adding a card to a business partner using the Internal Browser option, you can right-click
and choose 'iPayment - Fill BP details', iPayment will then try to fill in the Business Partner details
from the currently selected business partner.
You have the option to remove a card if you no longer want it to be visible in the system.
You have the option to use One-time Credit Cards. This works by associating the Credit Card with
a specific document/incoming payment instead of associating it with a specific Business Partner.
The One-time Credit Card feature is enabled on Business Partner level. If you enable a customer
as a One-time customer all documents created will be a one-time document. All authorization
and settlement actions will expect a Credit Card connected directly to the document and will not
take into account the Credit Cards stored on the Business Partner. This means that you will not be
able to use the Credit Cards from the Business Partner on the document.
You are still able to store Credit Cards on the One-time customer to allow for creating incoming
and outgoing payments on account instead of having to always provide a one-time Credit Card.
This allows for easy settlement of outgoing and incoming payments where the customer wants to
pay/refund without a document.
To set a customer as a One-time customer please set the UDF iPayment – One time customer to
“Yes”.
After setting the UDF to “Yes” the customer is now considered a one-time customer.
The rest of the flow in iPayment is more or less the same as when not using a one-time customer.
The main difference is that you will be prompted to enter Credit Card details when adding
documents (depending on your settings) and when doing authorization/settlements.
Here a document with authorization set as automatic and a one-time customer is added:
You are then prompted to add “One-time Credit Card” details to continue with the authorization.
After entering the details in the browser iPayment will continue with the authorization (can take
up to 30 sec). The same will happen for settlement and if you try to open the authorization
window without any Credit Card details on the document.
The rest of the system works in the same way. You can refund settlements and you can make/void
authorizations.
Note: iPayment does not support splitting the authorization/settlement on multiple cards when
using a one-time Credit Card.
If you select the “Send link” option a link will get copied to the clipboard that you can then send
to the customer.
When the customer saves the Credit Card details the Credit Card will be associated with the
document and the user that requested the link will get notified.
Note: If the document is setup to automatically authorize this will be done and the approved flag
will be set if “Control sales order approval” is enabled.
For all gateways except Authorize.NET, it is possible to convert a one-time credit card into a
regular credit card, which is added to a business partner.
To do this, access the credit card form of a business partner, here you will find the "Convert one-
time card" button.
When you open the conversion screen, you will see a list of documents with one-time credit
cards available to convert. You then have the option of selecting the card you want to convert,
and confirming the choice by clicking OK. iPayment will then try to convert the one-time credit
card into a business partner card and attach it to the customer.
The “Mass link generator” tool allows you to export a list in CSV format of Business Partners,
emails and links that can be used to add a Credit Card to a Business Partner.
First you select the filters that you want to use. You can use the BP Group filter or you can create
your own filter using SQL. Next you select the customers that you want to export.
After selecting the customers you can press the “Export” button to start the export.
After selecting yes to start the export you have the option to get notified when Credit Cards are
added for a customer. If you select yes you will get an internal message when a customer adds
the Credit Card.
After selecting where the file should be saved the system will create a CSV file in the location you
have selected and you can then send out the links in your preferred way.
After enabling authorization on a document you will see a new tab on the document.
On this tab you can overwrite the “Use credit card as payment” and the “Authorization action”
before adding the document.
You can also see a log that shows information about what iPayment has done on this and parent/
child documents.
available:
“Yes” if this value is selected iPayment will depending on the setup try to authorize/settle the
document and control the sales order approval. This also makes the right-click options available
on the document and makes it show in the batch windows. You can still process the document as
a no credit card document (if for example the customer does not have a Credit Card). You are not
forced to complete the document flow by Credit Card if this is yes but iPayment will look at the
document when it is processed. You can always void all authorizations on the document to
prevent iPayment from settling it.
Once you have selected “Yes” and saved the document you cannot undo the selection. This is
required as the document many now have open authorizations/settlements and iPayment does
not allow you to change this as it would prevent iPayment from looking at the document going
forward.
“No” if this value is selected iPayment will not do anything with the document. Right-click
options are not available and the document will not be processed by iPayment. You can change
from “No” to “Yes” or “As business partner” later.
“As business partner” if this value is selected (This is the default value) iPayment will look at the
business partner to determine if it should do something. This value is directly related to the field
“Use Credit Card as payment method for this business partner”. If the field on the business
partner is checked the document will be treated as the option “Yes”. If the field is unchecked the
document will be treated as the option “No”,
Note: It is not recommended to change the “Use credit card as payment” option when using the
“Copy To” system in SAP. This might lead to having authorizations that will never be completed.
"Authorization action"
This option determines how iPayment should handle the Authorization when the document is
added to the system. The following values are available:
As configuration If this value is selected (This is the default value) the
configuration determines what iPayment should do
when the document is added.
Do nothing If this value is selected iPayment will not do anything
when the document is added.
Show authorization popup If this value is selected iPayment will show the
authorization popup that allow to authorize the
document with multiple Credit Cards and different
amounts (See the authorization chapter).
Automatic authorization If this value is selected iPayment will do an automatic
authorization where the document is added on the
default Credit Card on the business partner.
Note: If you on Business Partner have defined it to be one-time CC this will always be treated as
‘yes’ (even if the value says otherwise [can occur if document was created while iPayment was
not running or in background])
When doing an authorization or settlement without any previous authorization iPayment will
automatically check the fraud data returned by the gateway.
Secure Trading:
· AVS checking result will be checked.
Authorize.NET
· AVS and CAVV result will be checked.
CyberSource:
· AVS result will be checked
Eway:
· Nothing is checked
If one or more of the checks is returned as failed by the gateway iPayment will show a warning
message. It will be up to the user to respond to the message returned by the gateway and take
the appropriate actions.
You can see the result of the checks in iPayment tab on the documents:
7.8 Authorization
The following conditions must be fulfilled before an authorization for a document can be done:
· Document Pay with Credit Card must be set to “Yes” or “As business partner”
· Field on the document related customer “Use credit card as default payment” must be set
to “Yes”
· An active and default credit card exists on customer or the customer is a one-time
customer
Based on the configuration the Credit Card Authorization window will automatically pop-up after
creating a document or manual activation using right click on the document in OK mode and
selecting Authorization.
If the customer related to the document is setup to be consolidated to another customer then the
credit cards from the consolidated customer will be shown.
If the configuration allows it the markup value can be edited by the user to whatever is needed.
Note on markup: The markup should not be entered as part of the amount on the lines. The
markup is always applied to the last credit card selected.
The user can also see if an amount has already been authorized for the current document or base
documents that this document is created from.
Base documents example: If a delivery is authorized and have a markup value of 10 USD then the
Invoice will not be able to change the markup as the markup is already authorized. If an invoice
consists of multiple deliveries then it is the total sum of all the base documents that will be
shown as the markup value.
Clicking the button “Authorize” will contact the gateway with the credit card details and the
amount and submit an authorization request. A response will be sent and saved related to the
document.
Tip: You can add a new credit card by using the option in the dropdown.
At any given time the user can see the log on the iPayment tab on the document.
This will void/cancel all authorizations and you will then be able to start the authorization process
again.
This will make the Server Component try to make a new authorization instead of marking the
existing authorization as expired.
The Server Component checks authorizations and performs this action once every 12 hours.
7.9 Settlement window
The following conditions must be fulfilled before a settlement for a document can be done:
· Document Pay with Credit Card must be set to “Yes” or “As business partner”
· Field on the document related customer “Use credit card as default payment” must be set
to “Yes”
· An active and default credit card exists on the customer or the customer is a one-time
customer
You can activate the window manually using right click on the document in OK mode or selecting
edit on a batch settlement line.
When the window opens, it will by default suggest the best possible settlement option based on
existing authorizations and active Credit Cards. You have the option to change how the
settlement should be done.
You can split it on multiple Credit Cards or you can choose to settle a lower amount than the
current document total.
If you have an existing authorization on the document this will also be shown if the authorization
can cover the settlement and it has not expired.
The authorized amount column will now show the authorization and the Credit Card selection will
be read only as you cannot change the Credit Card on an existing authorization.
If you do not want to use the authorization you can right-click on the rows-header of the lines and
unlock it:
This will void the authorization during the settlement process (When you press OK) and you are
now free to choose another Credit Card to perform the settlement on.
Clicking the button “OK” will either settle document or save the changes to the batch settlement
window.
You have the option to create a "Pay now" link on invoice type documents.
This will allow you to send a link to the customer where they will be able to pay the amount that
was open on the document when the link was generated.
To access the functionality do a right-click on the document that you want to generate a link for:
A link will be copied to your clipboard that you can then send by email to the customer.
Important: When the link is generated it is not possible to revoke/cancel the link.
When the customer pays the invoice using the link this will be picked up by iPayment and the
incoming payment document will be created if this is enabled in the settings.
You will also get notified in SAP that the link has been paid.
Note: If the document amount changes between you sending the link and the link getting paid
the incoming payment will still be posted.
If the document is closed between you sending the link and the link getting paid the incoming
payment will be made as "on account".
7.11 "Add Credit Card" links
Rather than entering a customers credit card options for him, you have the option of sending
them an "Add credit card" link.
Once they visit the link, they will be taken to a hosted gateway page where they can enter their
credit card details.
Once they've done so, the iPayment Server Component will query the gateway to retrieve the
credit card token, and import it into iPayment, associated with the correct business partner.
You generate a link by going to the desired BP's credit card window and selecting the "copy to
clipboard" option as shown below.
When the credit card has been successfully imported, you will receive an internal system
message to inform you that the card was added.
You have the option to refund a document that was settled using iPayment.
The option can be found as a right-click menu item.
The system will void/refund the entire settlement and will cancel any incoming payment that has
been created by iPayment.
After the refund is done it will ask if you want to create a credit note.
If you press this option it will open the A/R Credit Memo window which can then be added to the
system.
Note: For A/R Down Payments you need to refund any invoice document before you can refund
the A/R Down Payment.
a.
3. Read the message and press “OK”
a.
4. The credit note will now open and you can add the lines that you want to refund:
a.
b. You need to manually add the amount and lines that you want to refund
5. Press add to save the Credit Note and refund the customer.
a.
b. IMPORTANT: When adding the Credit Note iPayment will refund it. This will
transfer the money to the customer.
This functionality will refund without any base transaction. This is the same as sending money to
the customer directly as no existing transaction is voided or refunded.
You have the option to refund a Credit Memo using one or more Credit Cards.
The following conditions must be fulfilled before a refund for a Credit Memo can be done:
· Document Pay with Credit Card must be set to “Yes” or “As business partner”. The
document cannot be linked to any other documents.
· Field on the document related customer “Use credit card as default payment” must be set
to “Yes”
· An active and default credit card exists on the customer
· The gateway supports CFT/ECC (Credit founds transfer/Expanded Credit Capabilities) and
that it is enabled in the configuration
· Note: One-time customers are not supported
To use this feature create the Credit Memo and then do a right-click "iPayment - Refund now".
In the window that opens you can choose the amount to refund and what Credit Cards should be
refunded:
After pressing "OK" the refund will be done and an outgoing payment will be created in this
feature is enabled in the configuration.
You have the option to settle an incoming payment using Credit Card.
To use this feature open the incoming payment and select the customer and the documents you
want to settle using Credit Card.
You can then open the payment means window and select the “Credit card” tab
Here you can press the “Select Credit Card”/”One time Credit Card” button to select/add a credit
card you want to settle on.
After selecting/adding the Credit Card the screen will be filled out with some data:
You can change the “Amount Due” column and add a second voucher to settle on multiple Credit
Cards or just do a partial settlement.
Note: It is important that you do not change any of the values other than the “Amount due” set by
the system as this may lead to the settlement not being done. It is also important that you now
add the payment to the system without including additional documents as the data for the
settlement has already been prepared.
Technical: The actual settlement is done when the payment has been added successfully to the
database. Should anything go wrong during the settlement a message will be shown (and an alert
will be sent if setup). The user then needs to correct the issue and cancel the incoming payment
and manually make it again. There is no automatic handling of settlements that are not
completed correctly with the gateway.
You have the option to refund payments created using the payments means system. To refund
the payment right-click and select “Refund now”
You will be asked to confirm that you want to refund the payment. If you confirm it will cancel the
payment and refund the transaction.
You have the option to refund an outgoing payment using Credit Card for a customer.
To use this feature open the outgoing payment and select the customer and the credit note you
want to refund using Credit Card.
You can then open the payment means window and select the “Credit card” tab
Here you can press the “Select Credit Card” button to select a credit card you want to refund on.
After selecting the Credit Card the screen will be filled out with data by iPayment. You can change
the “Amount Due” column and add a second voucher to refund on multiple Credit Cards or just do
a partial refund.
Note: It is important that you do not change any of the values other than the “Amount due” set by
the system as this may lead to the refund not being done. It is also important that you now add
the payment to the system without including additional documents as the data for the refund has
already been prepared.
Note: Using this feature is basically the same as sending money to the customer and it may
require special permissions at gateway level depending on the gateway. Please make sure that
your gateway account has the correct permissions.
Technical: The actual refund is done when the payment has been added successfully to the
database. Should anything go wrong during the refund a message will be shown (and an alert will
be sent if setup). The user then needs to correct the issue and cancel the payment and manually
make it again.
There is no automatic handling of settlements that are not completed correctly with the gateway.
iPayment supports using both business partner and one-time credit cards to handle deposits on
orders.
To do this, use the right-click menu "Payment Meants" on a Sales Order that is configured to use
credit cards.
Here you will have the option of selecting a credit card from the business partner or adding a one-
time card directly.
Doing this will automatically create an Incoming Payment linked to a Down Payment and settle it
against the gateway.
The Down Payment will be referred in the Remarks field on the Sales Order.
When doing a "Cancel" of a Sales Order/Delivery document that have one or more open
authorizations you will get a prompt:
If you choose "Yes" all open authorizations will be voided (including base/target documents).
If you choose "No" nothing is done by iPayment and you can cancel the document and keep the
authorizations.
iPayment includes a batch processing wizard, which allows you to search for various document
types based on relevant parameters.
The batch processing wizard replaces the Batch Refund, Batch Settlement and Batch Authorization
forms.
When you open up the batch processing window, you have several search options available to
you. These can be seen in the screenshot below.
It is also possible to filter on Business Partner properties by clicking the properties button in the
filter screen. This will take you to the BP Properties window.
If you are familiar with SQL syntax and want a more customized search, it is also possible to apply
your own SQL statements for filtering, ordering the output or selecting additional columns.
This is done using the Advanced window, which you can access by clicking the advanced button on
the filter form.
If you decide to add additional columns in the Advanced form, you have the option of formatting
the title of the column shown in the output. This is done by accessing the Advanced Format form.
After you have applied all the filters, you have the option of saving the filter template for future
use. This is done by clicking 'Save as template'. You will then have to name the template.
Templates are saved on a per-process basis. You can save different templates for Refunds,
Settlements and Authorizations.
Once the template is saved, several options will appear. These will allow you to Update, Delete
or set the template as the default template to be used when you open the form.
When you've input the desired search options, you can click the Next button to see the results.
The three result forms will be discussed one by one on the following pages.
They are very similar, but depending on the type of processing the output columns will vary
slightly.
7.20.1 Batch refund
Refund can be done from Banking -> Credit Card Processing -> Batch Refund.
Note: The batch refund screen requires that the gateway supports CFT/ECC (Credit founds
transfer/Expanded Credit Capabilities) and that it is enabled in the configuration
Here the user can select individual lines to refund or select all/none using the buttons to the
right.
Clicking “Refund” will process all selected lines one by one.
You have the option to change the amount to refund by editing the “Amount to refund” column.
Note: All lines shown in red are lines that cannot be processed at the moment due to an invalid
setup.
Note: The batch refund screen only shows credit notes that are not linked to any document (to do
a refund on an invoice document please use the right-click option on the document)
o
§ Please see the section “Settlement window” for information on how the
window works
Here the user can select individual lines to authorize or select all/none using the buttons to the
right.
Clicking “Authorize” will process all selected lines one by one.
Note: All lines shown in red are lines that cannot be processed at the moment due to an invalid
setup.
Tip: If you are looking for the older Schduled Processing system then please go here 103
The iPayment ServerComponent has the capability to do automatic authorization and settlement
of documents based on parameters you have specified.
Scheduling actions requires the BP to have a default credit card defined.
You'll find the menu item under Add-Ons-->B1 iPayment -->Scheduled Actions - once you click it,
you'll see the window shown below.
As an example, you might want to authorize documents 5 days before their DueDate,
in which case you'd include the DueDate as part of your WHERE condition.
Schedule Here you define the frequency you wish to execute the schedule on
You have the option of Minutely, Hourly, Daily, Weekly and Monthly schedules.
Preview You can press this button to see what data would be included in the currently selected
button filter.
Active Determines whether the action is currently active. Disabling this options means that
the ServerComponent will skip this action during processing.
NOTE: Since you'll be able to write the WHERE condition of an SQL statement, please make sure
that the condition only selects the documents you intend to do authorization or settlement on!
NB: This is the the old legacy Scheduler that only existed prior to iPayment 2018.10 release. Since
then we have introduced the new and improved scheduler. We are keeping this scheduler for
backward compatibility reasons but we recommend you use the new scheduler.
The iPayment ServerComponent has the capability to do automatic authorization and settlement
of documents based on parameters you have specified.
Scheduling actions requires the BP to have a default credit card defined.
You'll find the menu item under Add-Ons-->B1 iPayment -->Scheduled Actions (Legacy) - once you
click it, you'll see the window shown below.
NOTE: Since you'll be writing the WHERE condition of an SQL statement, please make sure that
the condition only selects the documents you intend to do authorization or settlement on!
iPayment also includes a settlment report, which allows filtering and searching for settlement
activities.
This report is useful for getting an overview of payments that have already been settled. Below
you see an example of a settled transaction, shown in the report.
The report requires you to specify a from and to date, to limit the search result, and prevent the
querying from taking too long.
On this screen you can list any transaction difference you might have.
Re-authorization of expired sales order authorizations can be done from: Sales – A/R -> iPayment
– Re-authorization.
To proceed with the re-authorization you selected the documents that you would like to re-
authorize. The re-authorization will be done on the same amount as the existing authorization
and it will mark the existing authorization as void.
Note: When doing re-authorization it expects the existing authorization to have expired. This
means that it will not void the authorization against the gateway but will just mark it as void in
the database.
Expert: If you need to change the default expiry value for the gateway you can do this in the User
Defined Table called BOY_E0_CONFIG. Locate the fields “ST – Reauth (Secure Trading)” or “AU –
Reauth (Authorize.NET)” to change the default expiry days. Please only change the default
values if you are sure that this is needed. Changing the value may lead to getting overlapping
authorizations as iPayment does not void the existing authorization as explained above. Default
for Secure Trading is 7 days. Default for Authorize.NET is 30 days.
After using the batch or re-authorization functionality a result window will show.
Lines in green are lines that was processed successfully and lines in red are lines that could not be
processed due to an error.
The error can either originate from iPayment or from the gateway depending on what the issue is.
In order to keep credit cards up to date a report can be extracted using dates and customer as
filter. The report can be found under Banking -> Credit Card Processing -> Credit Card Expiration.
If a customer’s credit cards is about to expire the customer should be notified so new credit card
details can be added to the system.
Note: This option is not available for Authorize.NET if the option “Use Credit Card form instead of
webpage” is disabled.
To handle prepayments in SAP you can create an A/R Down Payment Invoice based on the A/R
Sales Order.
First create the Sales Order and do the authorization either automatic or manually.
Now copy the sales order to the A/R Down Payment Invoice and add it.
Depending on the setup it will either automatically settle the down payment or you can settle it
manually using the batch settlement screen. You now have the money booked in SAP and you can
then close the sales order using a delivery document.
You have three options. You can use the iPayment “Batch settlement”, the right-click settlement
option on the document or you can use the incoming payment screen.
Batch settlement: After adding the document open the “Batch settlement” window and find the
document and change the settlement using the “Edit” button.
Should the customer want to settle the entire transaction at a point in the future you can use the
incoming payment to accept the remaining amount.
Note: you cannot use the option “Automatic settlement” if you want to do partial payments.
“Automatic settlement” will always settle the full amount.
You have the option to use the “Settle now” option on the invoice document to specify how to
settle the document. Please see the chapter “Settlement window”.
Alternatively you can use the incoming payment to settle the document using two vouchers:
To refund an entire document use the right-click option “iPayment - Refund now”. Please see the
chapter “Document refund”.
To do a partial refund please create a standalone “A/R Credit Note”. This credit note cannot be
linked to a document. After creating the credit note you can either refund it using the “Batch
Refund” window or using an outgoing payment.
Right-click refund on the Credit Memo
Please see the topic "Credit memo refund" 86
Batch refund:
Here you can change the “Amount to refund” column to refund the Credit Note and it will be
done on the default Credit Card on the business partner.
Outgoing payment:
You can refund money using the outgoing payment. You can refund to one or multiple Credit
Cards.
Steps to make:
1. Create the Credit Note and add it to the system
2. Open the Outgoing Payments window and mark you Credit Note
3. Open the Payment Means window and select the “Credit Card” tab
a.
4. Press the “Select Credit Card” button and mark or double click on the Credit Card you
want to use:
a.
5. Now the “Payment means” window will populate:
a.
6. Press “OK” and then add the outgoing payment.
7. The payment will now have been refunded by iPayment
8.
a.
9. Read the message and press “OK”
a.
10. The credit note will now open and you can add the lines that you want to refund:
a.
b. You need to manually add the amount and lines that you want to refund
11. Press add to save the Credit Note and refund the customer.
a.
b. IMPORTANT: When adding the Credit Note iPayment will refund it. This will
transfer the money to the customer.
12. The Credit Note has now been refunded to the customer
a.
When iPayment asks the gateway to settle a transaction the actually settlement is not processed
until in the night for most gateways. While the gateway does make certain checks to ensure that
the money can be pulled it is not known until later if the Credit Card will ultimately be rejected.
iPayment does not know the status when the transaction is finally processed and in case the
Credit Card is rejected later the users’ needs to manually control and handle this scenario.
iPayment does not have any automatic notification system as most gateways offer an email
notification system instead that will warn if transactions that are expected to pass are rejected. It
is important that the users receive the gateway warnings and proceed accordingly.
This is a manual process and should be done individually for the transactions that fail.
8.8 Reconciliation
To reconcile your bank account and move the money from the clearing account please use the
deposit feature in SAP. The deposit feature can be found under Banking -> Deposits -> Deposit.
The Credit Card tab will show all incoming payments created using a Credit Card. If the payment
was created by iPayment the voucher no. will be populated with the transaction reference
created by the payment gateway you are using. The transaction reference should allow you to
reconcile the payments when the money has been transferred to your bank account.
9 Troubleshooting
9.1 I get the error “-10 – Payment method not defined” when
iPayment does the settlement
Please make sure that you have defined what Payment Methods should be used for the Credit
Card payments in SAP.
10 SQL Queries
This topic contains MSSQL queries that can be used together with iPayment.
The SQL below will show all open orders without any Credit Card connected where either the
customer or the document is marked as "Use Credit Card".
SELECT
T0.DocEntry 'Document entry',
T0.DocNum AS 'Document number',
T1.CardCode AS 'Customer code',
T1.CardName AS 'Customer name',
CASE WHEN T0.DocTotalFC <> 0 THEN T0.DocTotalFC ELSE T0.DocTotal END AS 'Open Doc.
Total',
T0.DocCur AS 'Currency'
FROM ORDR T0
LEFT JOIN OCRD T1 ON T1.CardCode = CASE WHEN (ISNULL(T0.FatherCard, '') <> '' AND
T0.FatherType = 'P') THEN T0.FatherCard ELSE T0.CardCode END
LEFT JOIN [@BOY_E0_BPEXT] T3 ON T3.U_CardCode = CASE WHEN (ISNULL(T0.FatherCard, '')
<> '' AND T0.FatherType = 'P') THEN T0.FatherCard ELSE T0.CardCode END
LEFT JOIN [@BOY_E0_OTCC] T4 ON T4.U_DOCENTRY = T0.DocEntry AND T4.U_OBJECTTYPE = 17
WHERE
(
T0.U_BOY_E0_CCPAYEX = 'Y'
OR
ISNULL(T1.U_BOY_E0_OTCC, 'N') = 'Y'
OR
(T0.U_BOY_E0_CCPAYEX = 'B' AND T1.U_BOY_E0_CCPAY = 'Y')
)
AND ISNULL(T4.U_TRANSREF, ISNULL(T3.U_DefaultCard, '')) = ''
AND T0.DocStatus = 'O'
11 B1P&D integration
B1P&D have the option to integrate with B1 iPayment allowing for sending out one-time Credit
Card links automatically.
Please see the B1P&D manual for information on how to setup the integration.
The links generated by B1P&D will be treated in the same way as the links generated by
iPayment. Please see the topic "Send one-time Credit Card link" for more information.
-A- -G-
Action log 64 Gateway requirements 18
Alerts 50 General 40
All open sales orders without a Credit Card record 124 General use 64
Appendix 1 – iPayment Gateway and server component
flows 128
Assign credit cards to customers 64 -H-
Authorization 43, 76
How do I create a partial refund (Credit Card saved on
Authorization flow explanation 132
Business Partner)? 113
Authorize.NET 18, 26, 27, 27, 34
How do I create a partial refund for a one-time
Automatic fraud check on authorization/settlement 75 document? 116
How do I handle partial payments? 111
-D- -L-
Data theft 11 License 30
Database Information 30
Document refund 84
Document refund – partial 84 -M-
Mass link generator (Secure Trading Only) 71
-E-
Eway 22, 22, 23, 27, 36 -O-
One-time Credit Cards/Customers 67
Outgoing payment – refund (Send money to customer)
90
-P-
Payment terms 51
Permissions 49
PII/PCI 11
-R-
Re-authorization of Sales Orders 105
Reconciliation 118
Result window 106
-S-
Secure trading 18, 26, 32, 37, 38
Secure Trading - Currencies 53
Secure Trading - Customizing the “Add credit card” page
52
Send one-time Credit Card link (Secure Trading only) 69
Settlement and refund 45
Settlement window 79
SQL Queries 124
-T-
Transactions rejected after settlement (Manual process)
118
-V-
Void authorization 78
-W-
What is Credit Card Tokenization and why is it
important? 14