B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S

B1 iPayment
B1 iPayment
© 2019 Boyum Solutions A/S

Boyum Solutions A/S
Table of Contents 3
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
2. Card store/CIM system and Credit Card details (Tokenization) 13

2.1 What is Credit Card Tokenization and why is it important? ......................................... 14
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
4. General must read notes on gateways 25

4.1 Secure Trading ................................................................................................................... 26
4.2 Authorize.NET .................................................................................................................... 26
4.3 CyberSource ....................................................................................................................... 26
4.4 Eway ................................................................................................................................... 27
4.5 Moneris Canada ................................................................................................................. 27
4.6 Cayan .................................................................................................................................. 27
4.7 ProPay ................................................................................................................................ 27
5. Setup 29
5.1 License ................................................................................................................................ 30
5.2 Database Information ....................................................................................................... 30
5.3 Configuration ..................................................................................................................... 31
B1 iPayment © 2019 Boyum Solutions A/S

Table of Contents 4
5.3.1 Secure trading ............................................................................................................. 32

5.3.2 Authorize.NET .............................................................................................................. 34
5.3.3 CyberSource ................................................................................................................. 35
5.3.4 Eway ............................................................................................................................ 36
5.3.5 Moneris Canada .......................................................................................................... 37
5.3.6 Cayan ........................................................................................................................... 38
5.3.7 ProPay .......................................................................................................................... 39
5.3.8 Square .......................................................................................................................... 39
5.3.9 General ........................................................................................................................ 40
5.3.10 Authorization ............................................................................................................... 43
5.3.11 Settlement and refund ................................................................................................. 45
5.3.12 Credit Card mapping ................................................................................................... 47
5.3.13 Permissions ................................................................................................................. 49
5.3.14 Alerts ........................................................................................................................... 50
5.3.15 Payment terms ............................................................................................................ 51
5.4 Secure Trading ................................................................................................................... 52
5.4.1 Secure Trading - Customizing the “Add credit card” page ......................................... 52
5.4.2 Secure Trading - Currencies ........................................................................................ 53
5.5 Special scenarios ............................................................................................................... 54
5.5.1 Handling large authorizations and split shipments .................................................... 54
5.5.1.1 Alternatives to creating large authorizations on Sales Orders ........................................................... 56
5.6 Credit Card Payment Methods ......................................................................................... 58
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

Table of Contents 5
7.10 "Pay now" links ................................................................................................................. 81

7.11 "Add Credit Card" links ..................................................................................................... 82
7.12 Document refund .............................................................................................................. 84
7.13 Document refund – partial ............................................................................................... 84
7.14 Credit Memo refund ......................................................................................................... 86
7.15 Incoming payment ............................................................................................................ 88
7.16 Incoming payment – refund ............................................................................................. 90
7.17 Outgoing payment – refund (Send money to customer) .............................................. 90
7.18 Deposit on Order ............................................................................................................... 92
7.19 Cancel of Sales Order/Delivery ........................................................................................ 93
7.20 Batch Processing ............................................................................................................... 94
7.20.1 Batch refund ................................................................................................................ 98
7.20.2 Batch settlement ......................................................................................................... 99
7.20.3 Batch authorization ................................................................................................... 101
7.21 Scheduled Processing ..................................................................................................... 101
7.22 Scheduled Processing (Old Legacy version) .................................................................. 103
7.23 Settlement Report .......................................................................................................... 104
7.24 Transaction Difference Report ....................................................................................... 105
7.25 Re-authorization of Sales Orders ................................................................................... 105
7.26 Result window ................................................................................................................. 106
7.27 Credit Card Expiration ..................................................................................................... 107
8. Common use cases 109

8.1 How do I handle prepayments? ..................................................................................... 110
8.2 How do I handle partial payments? .............................................................................. 111
8.3 How do I settle on multiple Credit Cards? .................................................................... 113
8.4 How do I refund everything? ......................................................................................... 113
8.5 How do I create a partial refund (Credit Card saved on Business Partner)? .............. 113
8.6 How do I create a partial refund for a one-time document? ...................................... 116
8.7 Transactions rejected after settlement (Manual process) ........................................... 118
8.8 Reconciliation .................................................................................................................. 118
9. Troubleshooting 121
9.1 I get the error “-10 – Payment method not defined” when iPayment does
the settlement ................................................................................................................. 122
10. SQL Queries 123

Table of Contents 6
10.1 All open sales orders without a Credit Card record ..................................................... 124
11. B1P&D integration 125

12. Appendix 1 - iPayment Gateway and server component flows 127
13. Appendix 2 - Authorization flow explanation 131
Index 133

iPayment general
iPayment general 8
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.
1.1 iPayment and Payment Card Industry Data Security Standard

(PCI-DSS)
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

iPayment general 9
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.
1.2 GDPR Notes
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 becomes enforceable from 25 May 2018.
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

iPayment general 10
•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
Credit card data

iPayment does not store any sensitive credit card payment information (please refer to the other
sections for further details), but it does store the masked credit card number along with name and
address information associated with the card when we receive it from the gateway.
This information is used exclusively for display purposes, to make it easier for the users to identify
unique cards/cardholders.
The data is not used when performing transactions and is not sent to 3rd parties at any point.
Update: From version 2018.10 version you can in main configuration choose the option to not store name
and address info using feature: "Save Credit Card to Business Partner record when importing
transactions 40 "
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.
1.3 iPayment and Payment Application Data Security Standard

(PA-DSS)
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?

iPayment general 11
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.
1.5 Data theft
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.
1.6 Known limitations in iPayment
· Business Partners
o “All Currencies” Business Partners are not supported as the token is only valid for
one specific currency.

iPayment general 12
· Secure Trading – Tokens

o For Secure Trading auth token are used. If Secure Trading starts to archive auth
tokens they will no longer be available on the Business Partners. Secure Trading
does not archive tokens today but they might in the future. Archiving tokens
would lead to old tokens disappearing from the business partner Credit Cards
window as they would no longer be valid.

Card store/CIM system and Credit Card details
(Tokenization)
Card store/CIM system and Credit Card details (Tokenization) 14
2 Card store/CIM system and Credit Card details (Tokenization)

As per the technical guidelines for PCI data storage:
[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)
2.1 What is Credit Card Tokenization and why is it important?
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.

Gateway requirements
Gateway requirements 18
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.1 Secure Trading
Please carefully read the requirements below.

· Merchant account with Secure Trading
o Share site security key with Secure Trading support
1. See configuration for more information on this
o Have Secure Trading support enable CFT (Cardholder Funds Transfer) on the site
(For doing refunds without a linked transaction)
o Have enhanced POST enabled for your site reference (Write to
support@securetrading.com)
3.2 Authorize.NET

· Account with Authorize.NET
o The Transaction Details API must be enabled.
o To enable the Transaction Details API:
1. Log on to the Merchant Interface at https://account.authorize.net .
2. Select Settings under Account in the main menu on the left.
3. Click the Transaction Details API link in the Security Settings section. The
Transaction Details API screen opens.
4. If you have not already enabled the Transaction Details API, enter the
answer to your Secret Question, then click Enable Transaction Details API.
5. When you have successfully enabled the Transaction Details API, the
Settings page displays.
o Have Extended Credit Capabilities (ECC) enabled (For doing refunds without a
linked transaction). More info on how to activate here: http://
www.authorize.net/content/dam/authorize/documents/ecc.pdf
o Have the account created in the correct currency. The Authorize.NET API does not
have support for currencies. The Authorize.NET account needs to be setup in the
currency that you will be using.
· If you want to test please get a sandbox account from http://developer.authorize.net/

o A standard Authorize.NET account can only be used in “Live” mode as

Authorize.NET does not allow normal accounts to login to the sandbox.
3.3 CyberSource

· Please carefully read the CyberSource documentation for the processor that you have
opted to use.
o Below you will find functionality requirements that the processor needs to support.
· The selected processor should have support for automatic preauthorizations + automatic
Preauthorization Reversal (See cybersource documentation for a list of processors that
support this: http://apps.cybersource.com/library/documentation/dev_guides/
Payment_Tokenization/UBC/Payment_Tokenization_UBC.pdf)
o Note: Contact your merchant account provider to determine whether you will be
charged a fee for a preauthorization.
· Automatic Preauthorization Reversal should be enabled on your account.
· Subscription/Tokenization should be enabled on your account.
· The processor should support “Card verification number”
· The processor should support “Full Authorization Reversal”
· The processor should support “Automatic Preauthorization Reversal”
· If you want to test please get a sandbox account from http://www.cybersource.com/
register/
o A standard CyberSource account can only be used in “Live” mode as CyberSource
does not allow normal accounts to login to the sandbox.
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

· On the profile page press “Payment Form”

o Select the “Single Page Form” option
o Enable “Billing information” under “Checkout steps”
§ Enable the following fields and set them as display, edit and require:
· First Name
· Last Name
· Street Address 1
· City
· State
· Postal Code
· Country
· Email Address
·
§ 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.
The ipayment.boyum-it.com website is hosted on Microsoft Azure but we do not guarantee

uptime or availability of the service.
3.4 Eway

· Account with Eway
o Ensure that the account you’re using with iPayment has the ‘RapidAPIUser’ role
o Ensure that the ‘RapidAPIUser’ role has permissions to do ‘Rapid API Refunds’
3.5 Moneris Canada

· Account with Moneris Canada

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

· Account with Cayan
3.7 ProPay

· Account with ProPay
· Account must be configured to allow Direct Refunds (refunds not tied to previous
transactions)
3.8 Square

· Account with Square.
· Square specific UDFs must be set up in your database according to the Square
documentation (partially shown below, but please refer to Square own documentation
for more information).


General must read notes on gateways
General must read notes on gateways 26
4 General must read notes on gateways

4.1 Secure Trading
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
or the gateway. The CVV code will only be validated once when adding the card. It is not legal to
4.3 CyberSource
CVV codes
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.”

General must read notes on gateways 27
4.4 Eway
CVV codes
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.
4.5 Moneris Canada
CVV codes
4.6 Cayan
CVV codes
4.7 ProPay
CVV codes

Setup
Setup 30
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.
5.2 Database Information
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.

Setup 31
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

Setup 32
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 reference Enter the Secure Trading site reference

User Enter the Secure Trading user (this user needs to be
configured on the site with role “Webservices”)
Password Enter the Secure Trading password associated with the
user

Setup 33
Site security Enter a shared site security key (this key must be send to
Secure Trading support along with the site reference)
The email to Secure Trading support should contain the

following:
I would like to update the sitesecurity for my account.
Parameters are:
1. currency
2. mainamount
3. sitereference
4. orderreference
5. credentialsonfile (optional)
6. PASSWORD
Password: The password you have entered into the site

security field
Note: You should only include the 'credentialsonfile' field

if you have the 'Use credentials on file declaration' option
enabled. See Configuration-->General for further details.
Demo mode If you enable this option you will use a test account with
Secure Trading. All transactions will be in test mode and
you will be able to test the product without having a
Secure Trading account. You can do settlements, refund
etc. in a secure demo environment.
To test credit cards please use the following details:
Card type: VISA
Card number: 4111111111111111
Expiry date: 01/2034
Security code: 413
To test the account check feature please use the following

details:
Valid account check info:

House name/no: 789
Postcode: TE45 6ST
Invalid account check info:

House name/no: 123
Postcode: TE12 3ST

Setup 34
5.3.2 Authorize.NET
API Login Enter the Authorize.NET API login

Transaction key Enter the Authorize.NET Transaction key
Live transactions Check to connect to the live API. If this is not checked you
will connect to the sandbox API.
Authorize.NET. All transactions will be in test mode and
you will be able to test the product without having an
Authorize.NET account. You can do settlements, refunds

The expiration date must be set to the present date or
later. Use 123 for the CCV code.
American Express 370000000000002

Discover 6011000000000012
Visa 4007000000027
JCB 3088000000000017

Setup 35
5.3.3 CyberSource
Merchant id Enter the merchant id of your CyberSource account

Certificate CyberSource use a Certificate system to validate that identity. Please
select the Certificate generated using the “…” button. The Certificate will
be saved in the database in encrypted form so that you do not have to
copy it to each machine that uses the add-on.
Please see the CyberSource documentation on how to generate and
download the Certificate: http://apps.cybersource.com/library/
documentation
dev_guides/security_keys/creating_and_using_security_keys.pdf
See section: “Generating Transaction keys”

Reporting username To determine the status of the transactions iPayment needs access to the
reporting functionality.
Please create a reporting user using the CyberSource Business Center.
Account management -> User administration -> Add User
After creating the user please input the username.

Reporting password Reporting user password
Profile ID, Access Key, These information is needed from the gateway in order to add Credit
Secret Key Cards. See Cybersource requirements at the beginning of this manual for
more information.

Setup 36
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
To test the credit card please use the following details:

First name John
Last name Doe
Email demo@demo.com
Street 1295 Charleston Road
City Mountain View
State CA
Postal Code 94043
Country US
Card type Visa
Card number 4111111111111111
Expiry month 07
Expiry year 2032
Security code 123
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)
Eway. All transactions will be in test mode and you will be

Setup 37
able to test the product without having an Eway account.

You can do settlements, refunds etc. in a secure demo
environment.

later. Use any 3 digits for the CCV code.
Use 4 digits for the CCV code on American Express

Mastercard 5105105105105100
Visa 4444333322221111
Diners 38520000023237
5.3.5 Moneris Canada
StoreId StoreId provided by Moneris Canada when you sign up for

an account.
API Key API Key is provided by Moneris Canada when you sign up
for an account - or generated by logging in to your Moneris
account.
Hosted Token ID This is obtained by logging in to the Merchant Resource
Center, navigating to Admin --> Hosted Card Tokenization
and creating a new Hosted Token Profile.
The Profile Id is the Hosted Token Id.
Moneris Canada. All transactions will be in test mode and
you will be able to test the product without having a

Setup 38
Moneris Canada account. You can do settlements, refund

Card type: VISA
Card number: 4242424242424242
Security code: 413
Card type: Mastercard

Card number: 5454545454545454
Security code: 142
5.3.6 Cayan
Merchant Name MerchantName provided by Cayan when you sign up for

an account.
Merchant Site Id Merchant Site Id is provided by Cayan when you sign up
for an account.
Merchant Key Merchant Key is provided by Cayan when you sign up for
an account.

Setup 39
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.

Setup 40
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.
Warning: Remember to setup B1P&D before enabling this option!

Save Credit Card to If this option is enabled iPayment will save the Credit Card details on the
Business Partner Business Partner record connected to the document imported from the
One-time Credit Card integration table. This means that the token created

Setup 41
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.
Note: The demo mode runs in USD.

Customers needs to have a specific currency set. You cannot use the
"Multi-currency" customer.
Data integration Authorize.NET only:
(Authorize.NET only) None:
This level is the default, which sends only the information required to
complete a transaction successfully.
Level II data:
This level includes additional information about shipping and tax rates if
these are available – providing these data may result in lower transaction
fees with your provider when working with P-Cards customers.
Other
Process credit notes Select this option if refunds should be possible without being linked to a
not linked to a base document/settlement
settlement
Secure trading
Requires CFT (Cardholder Funds Transfer) to be enabled
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.
If it is disabled then no personally identifying information is stored locally

on the Credit Card holder. This can make it easier to be GDPR compliant,
but you can no longer see any name, email or address on the card owner
in the Credit Card window.

Setup 42
Use 'card on file' Secure Trading only:

declaration when Enabling this option will send along a 'credentials on file' field in the
sending requests initial request when storing a card.
(Secure Trading only) For Visa cards it will also send along an 'initiation reason' field, containing
information on why the merchant has initiated the transaction.
Including these fields will decrease the likelihood of declines caused by

missing CVV codes when using cards on file.
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 Gateway Default, iPayment will not specify AuthMethod when

interacting with Secure Trading and Auths will happen using the method
defined on the gateway website
If set to Pre-authrisations, iPayment make all calls using the 'Pre-Auth'

Method. Read more about the Auth method via the More info link
If set to Final, iPayment make all calls using the 'Final' Method. Read more
about the Auth method via the More info link
More info: https://docs.securetrading.com/document/api/advanced/

auth-method/
ECI/Crypt Level Moneris Canada only:
(Moneris Canada only) This option controls which Moneris ECI/Crypt Level transactions are
processed with.
Please be aware that this setting applies to ALL processed transactions.

Some processors might have special rules and requirements that
transactions must fulfill to fit in a specific ECI/Crypt level.
It is your own responsibility to familiarize yourself with these rules, and
make sure you choose the right ECI/Crypt level for your scenario.
If you're unsure, please contact Moneris support, who should be able to

help you determine requirements for your processor.

Setup 43
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.
A/R Down Payment Invoice Select which authorization type you want to use.
A/R Invoice Select which authorization type you want to use.
A/R Reserve Invoice Select which authorization type you want to use.
Additional authorization options
Payment Terms Level BP Level:

Setup 44
Uses the Payment Terms on the Business Partner to

determine which Payment Terms Configuration to use.
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.
The dropdown next to the checkbox controls when

iPayment should switch the Approval flag to true.
Always: The Approval flag is set on any successful
authorization regardless of amount.
Only when fully authorized: iPayment will only set the
Approval flag when the total authorized amount for the
document exceeds the open document total.
Automatic Reauthorization Setting this flag tells the Server Component to
automatically reauthorize any authorizations that have
expired.
This service runs when the Server Component is first

started, and every 12 hours afterwards.
Authorization markup The purpose of the markup is to allow for authorizing a
higher start amount if you expect additional costs to be
applied at a later stage in the sales process e.g. Freight,
VAT.
When doing a settlement only the open document total
will be settled.
Note: This is not related to Credit Card fees and cannot be

used to apply additional fees to the order. Only the
document total will be settled.
Authorization markup type Select the appropriate markup type (None, Amount or
Percent)
Authorization markup value Enter the markup value and select the currency
Allow edit of markup at authorization Select this option if the user should be able to edit the
markup type and value in the authorization window
Authorization expire days This should be set to the value that the payment processor
has for when authorizations expire. The default value is
what the gateway has indicated as the normal expiry time.
The field should not be changed unless the processor has a

different expiry period than the default.

Setup 45
Note: You cannot control how long an authorization last

using this field as this is fully controlled by the processor
and the bank.
Changing the field impacts when iPayment will mark the
authorizations as expired but does not affect the actual
expiry date of the authorization.
5.3.11 Settlement and refund
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.
Note: The document will always be fully settled when

using the option. If you want to do partial payments you
should not use this option.

Setup 46
A/R Invoice Enable this option if you want the system to automatically
this is enabled.

A/R Reserve Invoice Enable this option if you want the system to automatically
this is enabled.

Settlement - other
Allow settling more than open Enable this option if you want to disable all checks that
document amount prevent settling a higher amount than what is currently
open on the document.
This will impact the batch settlement and right-click ->
settle now screens.
No checks will be performed and settlements can be done
on any amount.
Note: We do not recommend enabling this option.

Batch settle only authorized amount Enabling this will cause iPayment to only settle authorized
amounts when using the Batch Settlement Wizard.
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.

Setup 47
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.
5.3.12 Credit Card mapping

Setup 48
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.

Setup 49
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.

Setup 50
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

Setup 51
5.3.15 Payment terms

You have the option to overwrite some of the configuration on the payment terms window. This
is optional and if nothing is setup on the payment term the default values from the configuration
will be used.

Setup 52
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.
5.4 Secure Trading
5.4.1 Secure Trading - Customizing the “Add credit card” page

To customize the Secure Trading “Add credit card” page to look like a signup page instead of a
“Pay now” page we have included a .css file and a .js file. To use the files please do the following.
Locate the files in the iPayment install folder (Normally: C:\Program Files (x86)\SAP\SAP Business
One\AddOns\BOY\B1 iPayment\ResourceFolder).
The files are named: customchild.css and customchild.js.
Login to Secure Trading using https://myst.securetrading.net/login.
Open the “File manager” and upload the two files to Secure Trading.

Setup 53
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.
5.4.2 Secure Trading - Currencies

Secure Trading support various currencies – see all here http://webapp.securetrading.net/
currencycodes.html
Depending on the currencies, they need to be setup/mapped in SAP Business One. This can be
done in Administration -> Setup -> Financials -> Currencies

Setup 54
Here the International Code column needs to match a Secure Trading currency code provided in
the link above.
5.5 Special scenarios
5.5.1 Handling large authorizations and split shipments

When working with large authorizations and split shipments it is very important to consider how
this is handled.
If the proper work-flow is not used you may end up reserving more funds than the customer have
available leading to transactions getting rejected.
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:

Setup 55
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.
Example from CyberSource

"After the $25 settlement is processed against the original $100 authorization hold, the remaining
funds ($75) are still being held on the customer's card. Depending on the card type and payment
processor in use, CyberSource or your processor may initiate a partial authorization reversal
request against the $75 remainder of the funding hold once the $25 settlement request has been
received and processed by the payment processor. If the customer's issuing bank approves of the
partial authorization reversal, the remaining funding hold will be returned back to the card before
the $25 settlement funds completely; else,
the remaining funds being held will be returned to the customer's card once the funding for the $25
settlement completes."[Link]
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
Gateway specific functionality

Secure Trading have some very specific functionality to handle the above scenario. However this
comes with certain limitations.
· Only certain acquiring banks support split shipments
· Only VISA/Master Card can be used
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].

Setup 56
5.5.1.1 Alternatives to creating large authorizations on Sales Orders

Alternative 1 - Authorization at Delivery
To get around the issue with the large authorizations on the Sales Order one alternative is to
authorize at the Delivery instead of the Sales Order.
You would still add the one-time Credit Card/Business Partner Credit Card at the Sales Order as
this will create an (0.01) authorization to validate the Credit Card. This way you can still do the
fraud check without authorizing the full amount on the Sales Order.
The benefit of doing the authorization when creating the delivery is that you get the split
shipment authorized but you only authorize the amount that you are going to settle.
When the delivery is then copied to an A/R Invoice you settle the full authorization and you only
hold the money that you are going to settle on the customers Credit Card.
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.
Alternative 2 - One A/R Invoice

One alternative is to always settle using one A/R Invoice instead of multiple A/R Invoices.

Setup 57
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.
Alternative 3 - Only ship every 10 days

An authorization normally expires after 10 days so only shipping every 10 days would allow for
the settled authorization to expire before the next settlement is done.
You can get the specific expiration time for the authorization by contacting the gateway.
Alternative 4 - A/R Reserve Invoice

When creating the A/R Reserve Invoice document you can settle it using iPayment for the full
amount.
You can then close the A/R Reserve Invoice using one or more Delivery documents when the
delivery has been made.

Setup 58
5.6 Credit Card Payment Methods
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.

Go-live checklist
Go-live checklist 60
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
2) Configure your Payment gateway

Make sure that all the required features are enabled at the gateway and that you insert all the
required credentials into the iPayment gateway configuration window.
· Secure Trading Requirements 18

· Authorize.NET Requirements 18
· CyberSource Requirements 19
· Eway Requirements 22
· Moneris Canada Requirements 22
· Cayan Requirements 23
· ProPay Requirements 23
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.
3) Provide gateway access to your accounting team

The accounting team should have access the to gateway backend system so that they may
reconcile and verify the transactions.
All error handling in regards to rejected transactions are manual and the accounting team should
be instructed on how to handle this. 118
Additionally you may want to setup automatic e-mail notification on rejected settlement if this is
supported by the gateway.
4) Instruct your sales team in the new work-flow

Go-live checklist 61
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

General use
General use 64
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.
7.1 Action log
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”.

General use 65
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.

General use 66
You have the option to remove a card if you no longer want it to be visible in the system.
Test Credit Cards

Secure Trading To test credit cards please use the following details:
Card type: VISA
Card number: 4111111111111111
Security code: 413
To test the account check feature please use the following

details:
Valid account check info:

House name/no: 789
Postcode: TE45 6ST
Invalid account check info:

House name/no: 123
Postcode: TE12 3ST
Authorize.NET To test credit cards please use the following details:
later. Use 123 for the CCV code.

Discover 6011000000000012
Visa 4007000000027
JCB 3088000000000017
CyberSource To test the credit card please use the following details:

General use 67
First name John

Last name Doe
Email demo@demo.com
Street 1295 Charleston Road
City Mountain View
State CA
Zip 94043
Country US
Card type Visa
Card number 4111111111111111
Expiry month 07
Expiry year 2032
Security code 123
7.3 One-time Credit Cards/Customers
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”.

General use 68
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.

General use 69
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.
7.3.1 Send one-time Credit Card link (Secure Trading only)

You have the option to send a link to the customer allowing them to associate their Credit Card
with a specific document in SAP. This way the customer can enter the Credit Card details in a
secure environment without any employees seeing the Credit Card details. When adding the
document you get prompted to choose how to add the 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.

General use 70
7.4 Converting a One-Time Credit Card to a BP credit card
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.

General use 71
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.
Please note: This feature is not available for Authorize.NET.
7.5 Mass link generator
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.

General use 72
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.

General use 73
7.6 B1 iPayment tab on documents
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.
"Use credit card as payment"

This field controls if iPayment should look at the document or not. The following values are

General use 74
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"

General use 75
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.
"One-time Credit Card"

Here you define if the document should use a one-time credit card instead of a card defined 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])
7.7 Automatic fraud check on authorization/settlement
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:

General use 76
Testing the fraud features:

Secure Trading please visit: http://www.securetrading.com/files/documentation/STPP-AVS-and-
CVV2.pdf
Authorize.NET please visit: http://developer.authorize.net/hello_world/testing_guide/
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

General use 77
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.
Note: Not possible with a one-time customer.

Example where an invoice was made using the “Copy from” system.

General use 78
At any given time the user can see the log on the iPayment tab on the document.
7.8.1 Void authorization

You have the option to void the authorization using the “Void Authorizations” button
This will void/cancel all authorizations and you will then be able to start the authorization process
again.
7.8.2 Automatic re-authorization

It is possible to have the iPayment Server Component automatically try to re-authorize
authorizations when they have expired.
To enable this, you need to configure it in the configuration screen.

General use 79
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”
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.

General use 80
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:

General use 81
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.
7.10 "Pay now" links
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.

General use 82
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.

General use 83
When the credit card has been successfully imported, you will receive an internal system
message to inform you that the card was added.

General use 84
7.12 Document refund
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.
7.13 Document refund – partial
To do a partial refund on a document please follow the steps below.

1. Find the invoice document that you want to refund.
2. Right-click and press “Partial refund”
a.
3. Read the message and press “OK”

General use 85
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.

General use 86
6. The Credit Note has now been refunded to the customer
7.14 Credit Memo refund
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.
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".

General use 87
In the window that opens you can choose the amount to refund and what Credit Cards should be
refunded:

General use 88
After pressing "OK" the refund will be done and an outgoing payment will be created in this
feature is enabled in the configuration.
7.15 Incoming payment
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.

General use 89
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.

General use 90
7.16 Incoming payment – refund
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.
7.17 Outgoing payment – refund (Send money to customer)
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.

General use 91
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

General use 92
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.
7.18 Deposit on Order
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.

General use 93
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.
7.19 Cancel of Sales Order/Delivery
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.

General use 94
7.20 Batch Processing
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.

General use 95
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.

General use 96
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.

General use 97
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.
NOTE: Template names are unique.

General use 98
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

General use 99
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)
7.20.2 Batch settlement

Settlement can be done from Banking -> Credit Card Processing -> Batch Settlement.
Note: You do not need to authorize to settle. If no authorizations are made the settlement will be
made directly.

General use 100
· Select the document type at the top to process.

o You can select individual lines to settle or select all/none using the buttons to the
right.
· You have the option to edit how the settlement should be done clicking the edit icon on
the settlement line.
o
§ Please see the section “Settlement window” for information on how the
window works

General use 101
· Clicking “Settle” will process all selected lines one by one.

o The document and payment will always be settled on today’s date.
7.20.3 Batch authorization

Multiple authorizations can be executed from Banking -> Credit Card Processing -> Batch
Authorization.
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.
7.21 Scheduled Processing
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.

General use 102
You'll find the menu item under Add-Ons-->B1 iPayment -->Scheduled Actions - once you click it,
you'll see the window shown below.
The window allows you to configure the following parameters:

Name A given name for the action to help you identify it.
Action Determines what action to perform on the documents that match. It's possible to
authorize or settle documents using the scheduled actions.
Success/ Who should get emails once the action is complete (optional) or if it encounters any
Error issues (Mandatory)
Email
Type Determines what type of documents this action will be performed on.
Filter Here you set the filter on Document, Amount and Business Partner for the set of
criteria that should be met before it will be included in the scheduled action.
Advanced if above filter is not enough you can used the advanced filter that allow you to write
your own Where-condition used to select the documents on which the action is
performed.
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

General use 103
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!
NOTE: Scheduled Actions do not support mark-up amounts.
7.22 Scheduled Processing (Old Legacy version)
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.

General use 104
The window allows you to configure the following parameters:

Name A given name for the action to help you identify
it.
Type Determines what type of documents this action
will be performed on.
Action Determines what action to perform on the
documents that match the WHERE condition. It's
possible to authorize or settle documents using
the scheduled actions.
Where Condition The WHERE condition used to select the
documents on which the action is performed.
Seeing how actions are recurring, you will most
likely want to include some sort of time-
component in the WHERE condition.
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.
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 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!
NOTE: Scheduled Actions do not support mark-up amounts.

7.23 Settlement Report
iPayment also includes a settlment report, which allows filtering and searching for settlement
activities.

General use 105
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.
7.24 Transaction Difference Report
On this screen you can list any transaction difference you might have.
7.25 Re-authorization of Sales Orders
Re-authorization of expired sales order authorizations can be done from: Sales – A/R -> iPayment
– Re-authorization.

General use 106
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.
7.26 Result window
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.

General use 107
7.27 Credit Card Expiration
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.

Common use cases
Common use cases 110
8 Common use cases

8.1 How do I handle prepayments?
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.
8.2 How do I handle partial payments?
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.

Right-click settlement option: Please see the section “Settlement window”.

Incoming payment screen: After adding the document open the incoming payment window and
find the document. Change the “Total payment” column to reflect the payment to settle and
proceed as explained in the chapter “Incoming payment”.
Note: you cannot use the option “Automatic settlement” if you want to do partial payments.
“Automatic settlement” will always settle the full amount.

8.3 How do I settle on multiple Credit Cards?
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:
8.4 How do I refund everything?
To refund an entire document use the right-click option “iPayment - Refund now”. Please see the
chapter “Document refund”.
8.5 How do I create a partial refund (Credit Card saved on Business

Partner)?
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.
8.6 How do I create a partial refund for a one-time document?
Note: This functionality is not available for Eway

To do a partial refund on a one-time document please follow the steps below.
7. Find the invoice document that you want to refund.
8. Right-click and press “Partial refund”
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.
8.7 Transactions rejected after settlement (Manual process)
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.

Troubleshooting
Troubleshooting 122
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.

SQL Queries
SQL Queries 124
10 SQL Queries
This topic contains MSSQL queries that can be used together with iPayment.
10.1 All open sales orders without a Credit Card record
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'

B1P&D integration
B1P&D integration 126
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.

Appendix 1 - iPayment Gateway and server
component flows
Appendix 1 - iPayment Gateway and server component flows 128
12 Appendix 1 - iPayment Gateway and server component flows



Appendix 2 - Authorization flow explanation
Appendix 2 - Authorization flow explanation 132
13 Appendix 2 - Authorization flow explanation

iPayment only starts the authorization/settle process after the document has been added. This
way we can be sure the data is in the database and that we authorize on the correct document
and that nothing else is blocking the sales order from getting added (Like a stored procedure). We
do it this way to avoid the scenario where the authorization is added to the gateway, the sales
order add is blocked by the transaction notification/another add-on and the user then decides to
not add the sales order. In this scenario we would end up with an authorization that would not be
linked to any document.

Index 133
-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
-B- How do I handle prepayments? 110

How do I refund everything? 113
B1 iPayment 8 How do I settle on multiple Credit Cards? 113
Batch authorization 101
Batch refund 98
Batch settlement 99
-I-
I get the error “-10 – Payment method not defined” when
-C- iPayment does the settlement 122

Incoming payment 88
Incoming payment – refund 90
Card store/CIM system and Credit Card details
(Tokenization) 14 iPayment and Payment Application Data Security
Standard (PA-DSS) 10
Configuration 31
iPayment and Payment Card Industry Data Security
Credit Card Expiration 107
Standard (PCI-DSS) 8
Credit Card mapping 47 iPayment tab on documents 73
CyberSource 19, 26, 35
Cybersource and interaction with Add credit card [How
does it work] 22
Cybersource and interaction with Add credit card website
-K-
[Mandatory] 19 Known limitations in iPayment 11
-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

Index 134
-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

B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

B1 Ipayment: © 2019 Boyum Solutions A/S Boyum Solutions A/S

Uploaded by

Copyright:

Available Formats

B1 iPayment

© 2019 Boyum Solutions A/S

2. Card store/CIM system and Credit Card details (Tokenization) 13

4. General must read notes on gateways 25

B1 iPayment © 2019 Boyum Solutions A/S

5.3.1 Secure trading ............................................................................................................. 32

B1 iPayment © 2019 Boyum Solutions A/S

7.10 "Pay now" links ................................................................................................................. 81

8. Common use cases 109

10. SQL Queries 123

B1 iPayment © 2019 Boyum Solutions A/S

11. B1P&D integration 125

B1 iPayment © 2019 Boyum Solutions A/S

1.1 iPayment and Payment Card Industry Data Security Standard

B1 iPayment © 2019 Boyum Solutions A/S

1.2 GDPR Notes

It becomes enforceable from 25 May 2018.

B1 iPayment © 2019 Boyum Solutions A/S

Credit card data

1.3 iPayment and Payment Application Data Security Standard

B1 iPayment © 2019 Boyum Solutions A/S

1.5 Data theft

1.6 Known limitations in iPayment

B1 iPayment © 2019 Boyum Solutions A/S

· Secure Trading – Tokens

B1 iPayment © 2019 Boyum Solutions A/S

2 Card store/CIM system and Credit Card details (Tokenization)

2.1 What is Credit Card Tokenization and why is it important?

B1 iPayment © 2019 Boyum Solutions A/S

B1 iPayment © 2019 Boyum Solutions A/S

B1 iPayment © 2019 Boyum Solutions A/S

3.1 Secure Trading

Please carefully read the requirements below.

Please carefully read the requirements below.

B1 iPayment © 2019 Boyum Solutions A/S

o A standard Authorize.NET account can only be used in “Live” mode as

Please carefully read the requirements below.

B1 iPayment © 2019 Boyum Solutions A/S

B1 iPayment © 2019 Boyum Solutions A/S

· On the profile page press “Payment Form”

B1 iPayment © 2019 Boyum Solutions A/S

The ipayment.boyum-it.com website is hosted on Microsoft Azure but we do not guarantee

Please carefully read the requirements below.

3.5 Moneris Canada

Please carefully read the requirements below.

B1 iPayment © 2019 Boyum Solutions A/S

Please carefully read the requirements below.

Please carefully read the requirements below.

Please carefully read the requirements below.

B1 iPayment © 2019 Boyum Solutions A/S

B1 iPayment © 2019 Boyum Solutions A/S

4 General must read notes on gateways

B1 iPayment © 2019 Boyum Solutions A/S

4.5 Moneris Canada

B1 iPayment © 2019 Boyum Solutions A/S

5.2 Database Information

B1 iPayment © 2019 Boyum Solutions A/S

B1 iPayment © 2019 Boyum Solutions A/S

Site reference Enter the Secure Trading site reference

B1 iPayment © 2019 Boyum Solutions A/S

The email to Secure Trading support should contain the

I would like to update the sitesecurity for my account.

Password: The password you have entered into the site