Bibit Administrative Manual

Transcription

Global Commerce, Local Payments
Bibit Administrative Manual
Pre Release Version 1.0.2 – February 2003
Jan-Willem Aarts
Bibit Global Payment Services, Kosterijland 20, 3981 AJ Bunnik, The Netherlands – www.bibit.com
Table of content
About this Manual
1.1 Intended Audience
1.2 Feedback
1.3 Terminology
2
Overview of the payment process.
2.1 The payment process.
2.2 Communicating the results
3
The order report
3.1 What information does the order report provide?
4
The transfer report
4.1 What information does the transfer report provide?
4.1.1
The header
4.1.2
Management Summary
4.1.3
Transfer Details: Payments settled
4.1.4
Payment method overview
4.1.5
Transfer Details: charged-back payments
4.1.6
Transfer Details: refund payments
4.1.7
Transfer Details: Miscellaneous transactions
4.1.8
Deposit corrections
4.1.9
Transferred amounts
5
The capture report
5.1.1
Transaction overview
5.1.2
Payments settled
5.1.3
5.1.4
Payments charged-back
5.1.5
Payments refunded
6
The Merchant Interface
6.1.1
Status page
6.1.2
Payments page
6.1.3
Orders page
6.1.4
Profile page
6.1.5
Risk Management Module page
6.1.6
Dispute Management page
7
The Bibit invoice
8
Frequently Asked Questions
8.1 When to expect payments from Bibit?
8.2 What is the deposit for and when can I expect it back?
8.3 How can I do a refund?
8.4 How long does it take to fully process a refund?
8.5 How can I cancel a payment?
8.6 Why did I get a charge-back?
8.7 How can I prevent charge-backs?
8.8 Why doesn't this order have a payment status?
8.9 How can I increase the maximum transaction amount?
Index 36
3
1
3
3
3
5
5
5
6
6
7
7
7
7
7
7
7
7
7
8
8
10
11
11
11
11
11
12
12
14
17
17
27
28
32
33
33
33
34
34
34
34
35
35
35
1 About this Manual
This manual explains how the administrative tools of the Bibit Payment Service work. The administrative tools
described in this manual are the on-line Merchant Interface (http://www.bibit.com/merchant), the financial reports
(order, capture and transfer reports), the Risk Management Module and Dispute Management.
It will also explain how the money flows from the shopper to Stichting Derdegelden Bibit Internet Payments
(Stichting Trusted Third Party Bibit Internet Payments) to the merchant. This manual describes the flow from the
point of view of the money, to fully understand the flow from the point of view of the system, please read the
Implementation Manual. Certain functionalities or processes are not described in this manual but instead a
reference to the appropriate section of the Implementation Manual is provided.
1.1
Intended Audience
The intended audience for this manual are merchants who use the Bibit Payment Service for the processing of
their payments, merchants who are considering connecting to the Bibit Payment Service and technical staff who
need to know more about the administrative procedures to design a back-office system for merchants connecting
to the Bibit Payment Service.
1.2
Feedback
In order to improve the quality of this manual we would like to invite you to provide us with constructive feedback.
You can do this by sending an e-mail to: [email protected].
1.3
Terminology
Below you will find a list of terms used throughout this manual. Better understanding of these terms will greatly
improve the understanding of the process.
·
Merchant Interface: this is the online tool, which gives the merchant access to an overview of the
statuses of all the orders and payments processed by the Bibit Payment Service on the merchant's
behalf. The merchant interface also provides access to the Risk Management Module and Dispute
Management. It can be accessed from http://www.bibit.com/merchant using the merchant code and the
password.
·
Issuing bank: this is the actual bank that issued a particular shopper's credit card. Not all credit cards
need to be issued by the credit card companies.
·
Financial Institutions: these are the (issuing) banks, credit card companies, and acquirers that make up
the financial network the Bibit Payment Service uses to process transactions.
·
Acquirer: this is a financial institution that interfaces between the Bibit Payment Service and the card
issuing banks to obtain a response to the authorisation request in an order.
·
Reconciliation: this is the process of determining which payment belongs to which order and adding it to
the merchant's batch. Due to the different ways payment methods work and the way the financial
institutions operate, the time it takes for a certain payment to go through the full reconciliation process
differs from method to method.
Bibit Administrative Manual, version1.0.2
-3 -
2/12/03
·
Batch: in the context of this manual a batch is the collection of money the Bibit Payment Service has
received for a particular merchant, which has been reconciled. A batch generally covers a period of one
week.
·
Authorisation: is the permission, or the process of obtaining this permission, from the issuing bank to
debit a particular card for a particular amount. Authorisations have a typical 'lifespan' of 14 days.
·
Refusal: the merchant has not been given permission to debit a particular card for a particular amount.
Most of the time the issuing banks provide no specific reason.
·
Refund: the money debited from a card is being or has been refunded to the cardholder. In case of a
partial refund only a part of the money has been refunded.
·
Capture: the process of actually enforcing the authorisation to collect money from a credit card.
·
Information request: the issuing bank or credit card company have questions about a particular
transaction and ask the merchant to provide them with extra information. Not providing this information
may lead to a charge back.
·
Charge back: a charge back usually occurs when a cardholder has denied a particular transaction with
his credit card company or issuing bank. The credit card company will generally favour their customers,
the cardholders, and take the money back from the merchant and return it to the cardholder.
·
Dispute Management: an integral part of the Merchant Interface used for automatic communication
between the merchant and the acquirer in the case of an information request.
·
Risk Management Module: optional paid service used to manage the merchant's risk when accepting
credit card payments over the Internet. Access to this optional module is provided through the Merchant
Interface.
·
Order: an order is the collection of information that contains all the information about what a shopper
ordered at the merchant's shop. This is what is contained in the XML order sent to the Bibit Payment
Service.
·
Payment: is an order that has received a payment result. This can be any of the possible payment results
(i.e. refused, signed form received, cancelled, etc). So a payment doesn't necessarily mean actual
money has changed hands.
-4 -
2/12/03
2 Overview of the payment process.
This section provides a basic overview of the process of merchants receiving money from their shoppers. Later on
in this manual all parts of this process will be discussed in more depth.
2.1
The payment process.
From the moment all necessary payment details (bank account or credit card details) of the shopper are stored in
the Bibit Payment Service the actual payment process can start.
Below you will find a description of the payment process for a credit card:
1.
Payment details are sent to an acquirer
2.
The acquirer either authorised/refuses the transaction (this happens when the acquirer is the issuer of
the card) or contacts the issuing bank for an authorisation.
3.
The result of the payment (authorised/refused) is sent back to the Bibit Payment Service.
4.
The Bibit Payment Service will inform the merchant's system about the result. And the merchant's
system will inform the shopper.
5.
When the transaction has been refused the merchant can let the shopper try again using a different card
or payment method. The payment status of the order will be set to 'refused'.
6.
When the transaction has been authorised the payment status of the respective order will be set to
'authorised'.
7.
After a set period of time (Capture delay, standard 5 days) or a (manual) capture message from the
merchant's system, the Bibit Payment Service will instruct the financial network to transfer the money
from the cardholder to the Stichting Derdegelden Bibit Internet Payments. The capture delay can be set
by the merchant ranging from 0 to 14 days, or can be switched off completely, see section 6.1.4.
8.
After the money has landed on one of Bibit's bank accounts the money will be reconciled to the
appropriate order.
9.
The money is placed in the current batch of the merchant and will be paid out
2.2
Communicating the results
All communication between Bibit Payment Service and the merchant is done electronically over the Internet. This
can be done through e-mail messages or http messages as described in the Implementation Manual. Next to this
all orders and payments can be consulted through the online Merchant Interface (http://www.bibit.com/merchant)
and the Merchant test interface (http://www.bibit.com/merchant-test).
Next to the 24/7 real time information in the merchant interface there are several other ways the Bibit Payment
Service communicates to the merchant.
-5 -
2/12/03
·
Confirmation messages: these messages are sent after certain changes in the payment status of an
order. Not all merchants will want to use these messages, some merchants will use the XML responses
when using XML Direct.
·
Order reports: these daily reports provide the merchant with information about the orders that were
authorised the previous 24 hours.
·
Capture reports: these daily reports provide the merchant with information about all payments that were
captured the previous 24 hours. These reports are only available for selected merchants only.
·
Transfer reports: these weekly batch reports contain the reconciliation details for all payments that have
reached the 'settled' status and are being transferred or already have been transferred to the merchant's
bank account.
The confirmation messages are discussed in the Implementation Manual chapter 6.
3 The order report
The Bibit order report is sent to the merchant on a daily basis to notify the merchant of any changes in the orders.
The order report contains all the new orders since the last order report was created. These reports are created
automatically and cannot be resent.
3.1
What information does the order report provide?
·
OrderCode: this is the unique order code generated by the merchant's system which is passed on to the
Bibit Payment Service in the XML order.
·
Method: this is the payment method used for the transaction.
·
Currency: the currency used for the transaction.
·
Amount: the amount of the transaction
·
Status: the status of the transaction. Consult the Implementation Manual (section 6.1) for an overview of
all payment statuses.
·
Sum of authorised payments (EUR) : the total amount of the transactions in this report and the currency.
ORDER REPORT
Previous Report Date : 2002-7-23
This Report Date : 2002-7-24
Merchant : MERCHANTCODE
Number of orders : 5
OrderCode
Method
1235_abs
SOLO-SSL
EUR
16.70 AUTHORISED 2002-7-23
1238_abs
INCASSO_NL-FAX
EUR
35.75 AUTHORISED 2002-7-23
1245_abs
ECMC-SSL
EUR
11.85 AUTHORISED 2002-7-23
1250_abs
VISA-SSL
EUR
40.85 AUTHORISED 2002-7-23
1251_abs
ECMC-SSL
EUR
37.91 AUTHORISED 2002-7-23
Sum of authorised payments (EUR)
Currency Amount Status
EUR
-6 -
Date
203.06
2/12/03
4 The transfer report
The transfer report is also known as the 'batch' report as it contains the information about the batches paid out to
the merchant. It contains an overview of all payments and accounting transactions that affect the amount paid out
to the merchant. Its purpose is to explain and justify the transfer amount. Furthermore, it gives the merchant some
useful management information about the orders.
4.1
What information does the transfer report provide?
The transfer report consists of several sections.
4.1.1
The header
The report header contains the merchant code, the date the report was created, the batch number the report
concerns and the settlement currency.
4.1.2
Management Summary
The Management Summary provides the merchant with an overview of the number of payments and transactions
the report relates to. It shows the total amounts per currency.
4.1.3
Transfer Details: Payments settled
This part of the report contain the details of all the payments settled to the merchant.
·
OrderCode: this is the unique order code generated by the merchant's system which is passed on to the
Bibit Payment Service in the XML order.
·
Method: this is the payment method used for the transaction.
·
Shopper Payment: the colums show the currency and amount of the payment done by the shopper. Most
of the time, these are identical to the order currency and amount that the merchant sent to the Bibit
Payment Service, but in some cases, the currency can be different from the order currency.
·
Cost: specifies the costs of the financial institution for this transaction. The Bibit costs will be invoiced
separately once a month.
·
Net: is the net amount that Bibit owes the merchant for this transaction which will be transferred to the
merchant's bank account.
4.1.4
This information gives a summary of the number of settled payments per payment method
4.1.5
Transfer Details: charged-back payments
This provides an overview of all the transactions that have been charged-back. Charged-back amounts are debit
amounts and will reduce the amount transferred to the merchant. The costs of the charge-backs will be invoiced.
4.1.6
Transfer Details: refund payments
This section provides the details of all refunded payments in this transfer batch. Normally, refunds amounts are
debit amounts and will reduce the amount transferred to you. The costs of the refunds will be invoiced.
4.1.7
Transfer Details: Miscellaneous transactions
This section provides the merchant with the details of all miscellaneous transactions that relate to this transfer
batch. Miscellaneous transactions do not relate to a payment or an order. Some of these transactions relate to
foreign exchange transactions because Bibit may receive money in several currencies while an in individual
transfer is by definition in only one currency. Miscellaneous transactions can also relate to manual corrections.
-7 -
2/12/03
4.1.8
Deposit corrections
This section of the report provides information about which changes, if any, have been made in the deposit
position of the merchant.
4.1.9
Transferred amounts
This section of the report provides information about the total amount transferred to the merchant; it is the sum of
all transactions in this report minus the costs of the financial institutions. It also states the date the money was
transferred. The minus sign in the transaction amount indicates this is a debit amount (debited from Bibit). In
exceptional cases Bibit may deduct the monthly fees from the transferred amount. This only happens when
merchants do not pay the invoices even after repeated reminders.
TRANSFER REPORT
Merchant : MERCHANT
Report date : 2002-6-15
Batch number : 14
Currency of settlement : EUR
MANAGEMENT SUMMARY
TRANSACTIONS OVERVIEW
Debit
Credit
1 payments settled (EUR)
EUR
499.74
TRANSFER DETAILS
PAYMENTS SETTLED
(ordered by order code, grouped by payment method)
OrderCode
Method
Shopper
Payment
Cost
Net
Description
123545687890
ELV-SSL
EUR
500.00
Sum
-8 -
EUR
0.26
EUR
499.74
EUR
0.26
EUR
499.74
2/12/03
PAYMENT METHOD OVERVIEW
(SETTLED PAYMENTS ONLY)
Number
Payment method
1 ELV-SSL
1 Settled payments
No charged-back payments in this transfer report.
No refunds in this transfer report.
No miscellaneous transactions in this transfer report.
No deposit corrections in this transfer report.
TRANSFERRED AMOUNT(S)
(This amount equals the sum of all transactions in this report.
A debit amount, indicated by a minus, reflects a transfer from Bibit to the merchant.)
Description
transfer Jun 15 2002 5:53PM
Net amount
EUR
-9 -
-499.74
2/12/03
5 The capture report
The Bibit capture report is sent to the merchant on a daily report containing all the information about the captured
payments of that day. This report is only available for selected merchants. These merchants must have their own
accounts with acquirers. Though the merchant may select these reports in the report settings in the profile page of
the merchant interface, they will only be active when Bibit activates them.
Though it is a capture report it shows the settled payments. These are payments settled by the merchant, not by
Bibit as most of the merchants that are eligible for this report do their own cash management and use the Bibit
Payment Service for the reconciliation features.
CAPTURE REPORT
Merchant : MERCHANTCODE
Report date : 2002-1-7
Batch number : 69
Currency of settlement : GBP
MANAGEMENT SUMMARY
TRANSACTIONS OVERVIEW
Debit
Credit
4 payments sesttled by merchant (GBP)
GBP
4 payments refunded by merchant (GBP)
GBP
1,448.07
3,195.20
CAPTURE DETAILS
PAYMENTS SETTLED
(ordered by order code, grouped by payment method)
OrderCode
Shopper
Payment
BackOfficeCode
Method
Captured
G73520
330072091
ECMC-SSL
GBP
86.10
GBP
86.10
G94266
330097633
SWITCH-SSL
GBP
998.76
GBP
998.76
G94441
330097855
SWITCH-SSL
GBP
135.13
GBP
135.13
G73283
330071825
VISA-SSL
GBP
228.08
GBP
228.08
GBP
1,448.07
Description
Sum
2/12/03
- 10
-
PAYMENT METHOD OVERVIEW
(SETTLED PAYMENTS ONLY)
Number
Payment method
1 VISA-SSL
1 ECMC-SSL
2 SWITCH-SSL
4 Settled payments
No charged-back payments in this capture report.
PAYMENTS REFUNDED
OrderCode
Shopper
Payment
BackOfficeCode
Method
Captured
G30827
330024079
ECMC-SSL
GBP
1,039.88
GBP
-1,039.88
G34619
330027311
ECMC-SSL
GBP
2,011.57
GBP
-2,011.57
G40588
330032869
ECMC-SSL
GBP
145.36
GBP
-85.00
G85827
330087571
VISA-SSL
GBP
1,070.43
GBP
-58.75
GBP
-3,195.20
Description
Sum
5.1.1
Transaction overview
This section of the report provides information about the total number of transactions in this report, grouped by
settled, refunded and charged-back transactions.
5.1.2
Payments settled
This section of the report provides information about all the payments that have been settled by the merchant.
When the merchant uses 'back office code' it will be used in this report too. The list is ordered by order code and
grouped by payment method. The list states the shopper payment and the captured amount separately as it is
possible to do partial captures.
5.1.3
This section of the report provides an overview of all the payment methods that have been used.
5.1.4
Payments charged-back
This section of the report provides an overview of the payments that have been charged-back. In this example
there are no charge backs.
5.1.5
Payments refunded
This section of the report is an overview of the payments that have been refunded. The list is set up in the same
way as the 'Payments captured' list. The amounts are negatives as these amounts will be debited from the next
batch.
Please note: this report is available for selected merchants only!
2/12/03
- 11
-
6 The Merchant Interface
The merchant interface provides 24/7 real time online information about all the orders and payments for
merchants using the Bibit Payment Service. Next to all the real time information the merchant interface can also
be used to perform certain tasks on the payments. Tasks such as, refunding or cancelling a payment.
Several non payment-related tasks can also be done using the merchant interface. Amongst others these include
changing the location the reports are sent to, switching the sending of reports off and changing the automatic
capture delay.
Both environments have their own merchant interface:
·
http://www.bibit.com/merchant (production environment)
·
http://www.bibit.com/merchant-test (test environment)
These urls will redirect the browser to a secured environment where the merchant can log in using the merchant
code (all capitals) and the password.
6.1.1
Status page
The opening page of the merchant interface displays information about the financial position of the merchant. It
contains information about the amount that is to be transferred by the financial institutions and the amount that is
collected by Bibit and will be transferred to the merchant's account that period.
This information will also be shown when the merchant clicks on 'status' in the menu on the left side of the screen.
The status page contains the following information:
·
To be received from Financial Institution: the total of the captured and the authorised payments that have
not yet been transferred by the financial institutions to Bibit for the merchant's account.
·
To be transferred to Merchant: this is the amount that Bibit has been collected for the merchant, but not
yet transferred, in other words it's the batch total of the currently open batch. Normally this amount will be
transferred in the next batch.
·
Batches: open, closed. By clicking on 'closed' an overview of all closed batches will be shown, by clicking
on 'open' an overview of all open batches will be shown.
·
Transferred to Merchant: this is the total amount that has been transferred to the merchant. This amount
is zeroed after the transfer from the Bibit account to the merchant's bank account has been confirmed.
This could be used as a check whether or not the amount has been sent.
·
Deposit: the amount Bibit holds in deposit for the merchant.
2/12/03
- 12
-
To be received from Financial Institution
currency CAD
amount
EUR GBP USD
550.160,04 0,00
0,00
0,00
To be transferred to MERCHANTCODE
USD 0,00
Batches:
open
closed
none
Transferred to MERCHANTCODE
USD 0,00
Deposit
USD 0,00
6.1.1.1 Closed batches
When clicking on 'closed' in the 'batches' section, a list of all closed batches will be shown. Clicking on
'details' will open a screen with all the details of that batch. The descriptions 'AUTO', 'NO REFERENCE',
etc don't have any particular meaning for the merchant, these are codes used by the reconciliation
department at Bibit.
1 AUTO
closed: 06/06/2000 - 10:14 details
2
closed: 03/07/2000 - 17:07 details
3
closed: 10/07/2000 - 16:30 details
4
closed: 17/07/2000 - 16:35 details
5
closed: 24/07/2000 - 16:13 details
6 NO REFERENCE closed: 31/07/2000 - 17:41 details
7
closed: 08/08/2000 - 15:39 details
8 AUTO
closed: 04/10/2000 - 13:29 details
Below is an example of the details shown after clicking on 'details' in the 'closed' batch list. The
information below is from batch 23 for merchant DEMO. The online version only provides the basic
information about the batch.
2/12/03
- 13
-
details for batch nr. 23 of SETTLED_BIBIT_NET - DEMO
foreign code
23/07/2002 - 08:35
closed date
yes
balanced
Payments
amount
description
payment date
payment method
order code
EUR 0,77
17/07/2002 - 09:23
RABO-DIRECTBETALEN
EUR 0,97
18/07/2002 - 14:09
ECMC-SSL
EUR 0,97
6.1.2
03072002
18/07/2002 - 14:09
ECMC-SSL
EUR 0,77
DEMO1026824924097
03072002
deposit Jul 23 2002 8:35AM
Payments page
When clicking on 'Payments' in the menu on the left part of the screen the merchant will be presented with an
overview of all payments dating back to one month after today. This overview provides the following information.
·
Order code: this is the order code the merchant's system created when sending the order to the Bibit
Payment Service.
·
Creation date: this date indicates the date and time when the first payment result occurred. With online
payment methods like credit cards this date and time is virtually identical to the date in the orders page.
When a bank transfer is used as payment method the date the order was created and the date the first
payment status was reached usually aren't the same.
·
Amount: this is the amount of the payment.
·
Last event: this is the current payment status. More information about payment statuses can be found in
the Implementation Manual section 6.1.
·
Risk: this is the total score of the checks the Risk Management Module applied to the payment. Only
merchants who subscribe to the Risk Management Module are able to see this information.
The information in this page can be sorted on all and any of the above by activating the funnel shaped icons .
The filters can be used in combination for instance to filter all payments with a risk score higher than 90 for an
amount of Euro 80,50 and creation date 17/07/02.
Filters that are in use have a green bold funnel shaped icon.
2/12/03
- 14
-
When a specific transaction that should be there doesn't show up, an 'unwanted' filter might still be switched on.
Disabling a filter can be done by clicking on the respective green funnel shaped filter icon and clicking on
Disable amount filter. "Amount filter" will be replaced by the name of the respective filter. Please note that the
"creation date" filter cannot be switched off. Default it allows to search to 30 days back. This 30 day period can be
adjusted, but the filter itself cannot be switched off.
When searching for orders, a 'wildcard' can be used. If the merchant would like to search for all orderCodes
beginning with DEMO1238, the merchant can use DEMO1238%. The percentage sign will act as the 'wildcard'.
The 'wildcard' can only be used at the END of an orderCode! %EMO1237 will NOT work!!
When searching on FULL orderCodes the "creation date" filter is overridden and the interface will search through
ALL the merchant's orders.
When a selection shows more than 100 items the results will be shown over more than one 'page', moving
through the pages can be done by means of the green triangle shaped arrows
101-200
. Where the left arrow
moves to the previous page and the right arrow moves to the next page. The numbers between the arrows
indicate which selection is currently shown. In this example results 101 to 200 are shown on the page.
Please remember that not all orders will reach a payment status! For an overview of all orders go to the 'Orders
page', see section 6.1.3.
6.1.2.1 OrderContent
Clicking on the order code will show the orderContent as sent by the merchant's system in the lower part
of the screen. A summary is shown above the orderContent as sent by the merchant's system. Extra
information in this screen is the 'Internal order id', this is the number the shoppers should use as
payment reference when paying using bank transfers or certain off line payment methods.
6.1.2.2 Payment details
Clicking on the amount of a payment will open a page in the lower part of the screen with all the payment
details that are available for this particular payment.
creation date
23/06/2002 - 09:52
order code
123456780
amount
EUR 165,00
status
CAPTURED 3)
last update
23/06/2002 - 10:43 1)
brand-protocol
VISA-SSL
cardholder name
John Doe 2)
Refund 4)
EUR
165,00
refund
Warning: Pressing this button will refund the payment without asking for confirmation!
Payment status 5)
Description
Payment in the Bibit payment system
Amount
Amount
EUR 165,00
Amount secured by Bibit
EUR 165,00
Payment history 6)
2/12/03
- 15
-
Time
Event Type
Amount
23/06/2002 - 10:43
CAPTURED
EUR 165,00
23/06/2002 - 09:52
AUTHORISED
EUR 165,00
23/06/2002 - 09:52
SENT_FOR_AUTHORISATION
1.
Last update: this is the date and time the payment status was last up-dated, in other words when the
latest payment status change took place.
2.
Card holder name: is the name the shopper filled out when submitting the payment details
3.
Status: indicates the most recent payment status
4.
Refund: this functionality can be used to (partially) refund the payment in the case of a dispute with the
shopper or when part of the order could not be delivered or any other reason. The merchant fills out the
amount he wants to refund using a comma or point as decimal separator. Clicking the 'refund' button
CANNOT be undone! The amount field in the refund functionality is pre-populated with the maximum
amount that can be refunded for that particular payment.
5.
Payment status: gives a more elaborate status of the payment.
6.
Payment history: lists all the payment statuses (event type) the payment went through including the
date/time and the amount that was involved. The amount gives some additional information on the
event. However, for some Event Types, an amount will not be displayed. Here's a summary of the
different Event Types with an explanation of what the amount will indicate: AUTHORISED, CANCELLED,
EXPIRED, CAPTURED, SENT_FOR_REFUND, SETTLED_BY_MERCHANT,
REFUNDED_BY_MERCHANT, the amount indicates the authorised, cancelled, expired, etc. amount..
SETTLED, REFUNDED, CHARGED_BACK the amount is the sum of the settled, refunded or charged
back amount (net amount), and the commission of the acquirer. Also called the gross amount.
For all other Event Types, an amount will not be displayed, because there are no financial obligations
involved for the event (like SENT_FOR_AUTHORISATION or SIGNED_FORM_RECEIVED).
When the status of a payment has not reached 'captured' yet section 4) in the example above will look like this:
Payment capture
Date
31/07/2003
Capture
this payment
Amount
0
CAD
2,00
days from now.
Use , or . for decimal separator
Cancel
this payment.
The merchant can manually capture a payment by clicking on the 'capture' button and the merchant can select
the number of days after which he wants the capture to be executed from the pulldown menu. CAD 2 will be
captured. To do a partial capture, the merchant can change the amount to CAD 1 for instance. The merchant
should note that a payment can only be captured ONCE! When CAD 1 has been captured, the remaining CAD 1
can no longer be capture and should be re-authorised but submitting a new order for that amount to the Bibit
Payment Service.
The 'cancel' button will cancel the authorisation and in effect cancel the payment. Both the capture and the
cancellation requests are immediately executed by the Bibit Payment Service and are NON REVERSABLE!
2/12/03
- 16
-
6.1.3
Orders page
When clicking on 'Orders' in the menu on the left part of the screen the merchant will be presented with an
overview of all orders that have been submitted by the merchant's system. The overview provides the following
information.
·
Order code: is the order code the merchant's system created when sending the order to the Bibit
Payment Service.
·
Date: is the date and time that the order was submitted to and created in the Bibit Payment Service. The
orders can be sorted by date/time ascending or descending. Clicking on 'Date' will change the order of
the sort. The grey triangular icon indicates how the results are sorted,
indicates descending and
indicates ascending order.
·
Amount: is the order amount, the amount the merchant's system put into the order, the amount that will
be send to the financial institutes for authorisation.
·
Payments: indicates whether or not that particular order has received a payment status yet. The file icon
with a red arrow ( ) indicates that a payment status for this order is available.
6.1.3.1 OrderContent
Clicking on the order code will show the orderContent, as sent by the merchant's system, in the lower
part of the screen. A summary is shown above the orderContent as sent by the merchant's system. Extra
information in this screen is the 'Internal order id', this is the number the shoppers should use as
payment reference when paying using bank transfers or certain off line payment methods. In the
Implementation Manual the internal order id is referred to as 'reference id', see section 4.4.
6.1.3.2 Payment details
To view the payment details of an order that has received a payment status, the merchant has to click on
the file icon with a red arrow ( ). This will open a new window with a summary of the payment details.
Clicking on the amount will open a page with all payment details in the lower part of the main screen, as
described in section 6.1.2.2
6.1.4
Profile page
When clicking on 'Profile' in the menu on the left part of the screen the merchant will be presented with
the 'profile page'. This page displays an overview of the current settings in the Bibit Payment Service for
the merchant. Some settings cannot be changed by the merchant, others can.
Please
note:
all
changes
should
always
be
made
in
the
merchant
interface
(http://www.bibit.com/merchant), only the password for the merchant test interface and the XML
password for the test environment can be set in the merchant test interface.
Merchant MERCHANTCODE retrieved from database.
Merchant Code
MERCHANTCODE
Password
******
XML Password
******
Shop name
Merchant
Shop Url
http://www.merchant.com
Settlment Currency Code
EUR
2/12/03
- 17
-
Deposit Amount
EUR 1000,00
Country/language selection
yes
no
Make return page secure (HTTPSProxy)
yes
no
Send email to shopper when payment received
yes
no
yes
no
Capture delay (days)
5
Continue Button
Shopper e-mail Content Type
text
Maximum Transaction Amount
1000000(cents)
Contract Start Date (YYYY-MM, inclusive)
2001-08
Contract End Date (YYYY-MM, inclusive)
Technical Contact Person Name*
John Doe
Technical Contact Person Phone Number*
555 123 455687
Technical Contact Person e-mail Address*
[email protected]
Save Profile
Telephone Number Financial
Contact*
555 1235 455689
e-mail Address Financial Contact
[email protected]
Edit channels
Environment properties
Edit reports
Please note that all and any changes will take effect immediately!
·
Merchant code: shows the merchant code of the merchant. This is always in capital letters
·
Password: doesn’t show the actual password. Clicking on the yellow pencil will open a screen where the
password to log into the merchant interface can be changed. To change this password in the test
environment go to http://www.bibit.com/merchant-test. Please note that there is a time delay of about 15
minutes before the password changes take effect.
·
XML password: doesn’t show the actual password for XML. Clicking on the yellow pencil will open a
screen where the password needed to send XML to the Bibit Payment Service can be changed. To
change this password in the test environment go to http://www.bibit.com/merchant-test. . Please note
that there is a time delay of about 15 minutes before the password changes take effect.
2/12/03
- 18
-
·
·
Shop name: the name of the shop as registered in the Bibit Payment Service. This is one of the fields
sent to the financial institutions to be printed on the statement of the shopper. (What is actually printed is
decided by the issuing bank, not by the Bibit Payment Service)
·
Shop URL: this is the url of the shop or the corporate website of the merchant. This is one of the fields
sent to the financial institutions to be printed on the statement of the shopper. (What is actually printed is
decided by the issuing bank, not by the Bibit Payment Service)
·
Settlement Currency Code: this is the currency code of the currency used to settle all payments to the
merchant in. More information about currency codes can be found in the Implementation Manual,
Appendix III.
·
Deposit Amount: is the amount that is held in deposit by Bibit for the merchant. This deposit is to
safeguard the Stichting Trusted Third Parties from financial risks incurred by charge-backs etc.
·
Country/language selection: determines whether or not the language and country selection pull-down
menu will be visible in the payment selection screen. The country selection may determine which country
specific payment methods are presented to the shopper.
Please select language and country. If your payment method is not displayed,
please select the country of your bank.
English
NETHERLANDS
Select
·
Make return pages secure (HTTPSProxy): this determines whether or not the HTTPS Proxy will be
used to secure the merchant result urls. Bibit recommends this to be switched to 'yes'. More information
about the HTTPS Proxy can be found in the Implementation Manual, section 5.8.1.6
·
Send email to shopper when payment received: this switches this functionality on or off. When it is
switched on the shopper will be send an e-mail by the Bibit Payment Service when an order reaches the
payment status REFUSED or AUTHORISED. To set up this feature the merchant clicks on the yellow
pencil . See section 6.1.4.3 for more information about setting up this feature.
·
Capture delay (days): this determines the delay in the automatic capture of a payment. This can be set
between 0 and 14 days. This delay can be used to determine whether an order can be delivered, if not
the capture delay will give the merchant some time to check and/or cancel the order. The automatic
capture functionality can also be switched off. When automatic capture is switched off the merchant will
have to capture a payment manually through the merchant interface or by sending an order modification
XML message for that particular order. Once an authorisation has expired capture is no longer possible
and the order will have to be re-authorised (read: re-entered into the Bibit Payment Service and
authorised by the financial institutions).
·
Continue Button: indicates whether or not the 'click here to continue' link will be shown when the
shopper has chosen an offline payment method. Clicking on this link will send the shopper to the
appropriate merchant result url (pending url). More information about result urls can be found in section
5.8.1 of the Implementation Manual.
·
Maximum transaction amount: this is the maximum amount allowed per order, in cents. Orders of a
higher amount can only be processed using non-reversible payment methods such as SET payment
methods. The Bibit Payment Service automatically reduces the available payment methods for such
transactions. If the merchant has specifically switched of such payment methods, no payment method
may be shown.
·
Contract Start date (YYYY-MM, inclusive): is the date the contract (and billing) started. 2001-08
indicates that the contract started on the first of August 2001.
·
Contract End date (YYYY-MM, inclusive): is the date the contract is set to expire. This is usually left
blank and will only show a date when the contract has been terminated by the merchant or Bibit.
2/12/03
- 19
-
·
Technical Contact person Name*: is the name of the person Bibit can contact in case of technical
problems. The asterix (*) indicates that this field is mandatory.
·
Technical Contact Person Phone Number*: is the telephone number of the person Bibit can contact in
case of technical problems. The asterix (*) indicates that this fields is mandatory.
·
Technical Contact Person e-mail Address*: is the e-mail address of the person Bibit can contact in
case of technical problems. The asterix (*) indicates that this fields is mandatory.
·
Telephone Number Financial Contact*: is the telephone number of the person Bibit can contact in
case of financial questions. The asterix (*) indicates that this fields is mandatory
·
E-mail address Financial Contact: is the e-mail address of the person Bibit can contact in case of
financial questions.
Buttons:
·
Save profile: will save any changes made in the profile page.
·
Edit channels: will open a window where the merchant channels can be set up. For more information
about merchant channels see the Implementation Manual, section 6.3.
·
Environment properties: will open a window where the merchant can view the IP addresses currently
registered in the Bibit Payment Service. This information is read only. Only Bibit staff can change these
settings. To change these settings please open an incident in the support interface at
http://support.bibit.com.
·
Edit reports: will open a window where the merchant can see the status of the reporting settings and
can change the settings, i.e. switch off certain reports or add or delete recipients of reports, see also
section 6.1.4.5.
Some information in the profile page can be changed by the merchant himself without communicating
with Bibit. All items that have radio buttons, pulldown lists, or text fields can be changed by the merchant
and their functioning is explained in the previous section. Changing the items that have a yellow pencil
( ) next to them is explained in section 6.1.4.1 and onwards.
2/12/03
- 20
-
Please submit only one order per payment, otherwise the order will not be processed
and the money transfer will be reversed.
Please include the information below in your bank transfer statement or in your tele
banking screen. Take extra care in filling out the transaction reference number:
5451055. This number is used for automatic processing. If the transaction reference
number is incorrect, the order will not be processed and the money transfer will be
reversed.
NOTE!
Bank transfers from abroad will only be accepted if the additional transfer costs are
paid by the customer.
Your payment will be processed when your banktransfer is received.
The processing of off-line payments may take several days.
Please be sure to send your transfer to your bank!
BANK/GIRO
Overschrijvingskaart
Euro
Eurocent
Betalingskenmerk
€
Naar bankrekening
Mededelingen
5451055
Ten name
BIBIT Internet Payments
van
Adres
Kosterijland 20
Postcode
Plaats
Bunnik
Volgnummer
123
Handtekening
Rekening
MW S HOPPER
WEBSTRAAT 1
1234AB INTERNET
123456789
Op witte onderzijde niet schrijven
123456789+ 987654321<
3141592653589793238+ 00>
Continue
This 'continue' link can be switched of by the merchant, though Bibit does not recommend this.
This is an example of a screen shown to the shopper when selecting a Dutch bank transfer as the
payment method.
2/12/03
- 21
-
6.1.4.1 Changing the password
·
To change the password for the merchant interface click on the yellow pencil ( ), a new page will open
in the lower part of the screen. Type the desired password into the two fields and click the 'Set new
password' button. A password should consist of at least 8 characters and should contain at least three
numbers within the first 8 characters. Bibit staff do not have access to merchant's passwords, when a
merchant loses the password Bibit staff can only assign a new password. Anyone who has the
password/merchant code combination can access the merchant interface, and thus also change the
password. Changing this password in the test environment can only be done in the merchant test
interface (http://www.bibit.com/merchant-test). . Please note that there is a time delay of about 15
minutes before the password changes take effect.
6.1.4.2 Changing the XML password
·
Changing this password is done in the same manner as changing the password for the merchant
interface as described above (6.1.4.1) . Please note that there is a time delay of about 15 minutes before
the password changes take effect.
6.1.4.3 Setting up the e-mail feature
This feature can be set up by clicking on the yellow pencil (
the screen:
), a new page will open in the main part of
Please select the payment status for which you want to edit the email that is sent to the shopper.
MerchantCode : MERCHANTCODE
Language : nl
AUTHORISED
Currently the language settings cannot be changed, this should not be a problem when using the
standard western character set. In the pulldown menu the merchant can choose the payment status for
which the message needs to be send. After selecting a payment status, AUTHORISED for instance, the
main screen will load the fill out form for the actual text of the e-mail message that will be send out to the
shopper by the Bibit Payment Service.
2/12/03
- 22
-
MerchantCode : MERCHANTCODE
Reply Address
Language : nl
Status : AUTHORISED
[email protected]
Subject
Format
text/plain
text/html
Select status
Save
Show example
Show help
The merchant should fill out his own support e-mail address in the 'Reply address' field as this is where
the replies will be directed to when the shopper clicks on his 'reply' button in his e-mail software.
The 'Subject' field will show the subject of the message that is send to the shopper.
The merchant can choose what type of format the message will have, plain text or html by selecting the
corresponding radio button. When using html, do not use the <html></html> tags, these will be added
automatically by the system.
The large blank field can be used to fill out the actual text of the message.
In the text of the message two variables can be used: &ordercode; which will be replaced by the order
code the message refers to. And &ordercontent; which will be replaced by the orderContent as supplied
by the merchant to the Bibit Payment Service.
Clicking on 'save' will save the current message.
Clicking on 'select status' will enable the merchant to select another payment status and set up the email message for that payment status.
More information can be found by clicking on 'Show help'.
Please note that once the messages have been configured the feature will have to be switched on in the
'profile page'. This feature cannot be set up in the merchant test interface, it has to be set up in the
merchant interface. Once set up and activated in the merchant interface it will also work in the test
environment.
2/12/03
- 23
-
6.1.4.4 Editing the merchant channels
The merchant channels are the (e-mail or http) channels through which the Bibit Payment Service
communicates changes in the status of payments; these channels can be set up in by clicking on the
'Edit Channels' button in the 'profile' page. More information about channels can be found in the
Implementation Manual, section 6.3, more information about payment statuses can be found in the
Implementation Manual, section 6.1.
Merchant Channels (Production)
Protocol Active
yes
e-mail
Content
Address
text
[email protected]
xml
http://w w w .merchant.com/confirm.asp
Method
Response
Client
Certificate
no
yes
http
POST
[OK]
no
yes
no
Merchant Channels (Test)
Protocol
Active
yes
e-mail
Content
Address
cgi
[email protected]
cgi
http://w w w .merchant.com/confirm.asp
Method
Response
Client
certificate
no
yes
http
no
POST
[OK]
yes
no
Save
The green section contains the settings for the production environment and the pink section contains the
settings for the test environment. The description below provides instructions to set up the channels for
either environment.
Each protocol can be activated or deactivated by choosing the 'yes' or 'no' radio button in the 'active' field
for the respective channel (or protocol).
The 'Content' field determines what format will be used (text (cgi) or XML). The 'Address' field should
contain the address the confirmation messages have to be send to, an e-mail address and/or an url.
When using the http channel the url should include the 'http://' and a method has to be chosen. Any url
used should ALWAYS reply with an UNconditional [OK]. If http is used in combination with XML the
method should always be POST.
The 'Client Certificate' should only be used in case the merchant's system is set up to be able to receive
and verify Bibit's client certificate.
More information about sending an [OK] and client certificates can be found in the Implementation
Manual, sections 6.3.4 and 7.2.2 respectively. More information on methods can be found in our FAQ's
which can be found at http://support.bibit.com.
2/12/03
- 24
-
More information about the merchant channels can be found in the Implementation Manual, section 6.3.
6.1.4.5 Editing the report settings
The merchant can select the type of the periodic reports the Bibit Payment Service automatically
generates and sends to the merchant and also activate or deactivate them and change the addresses
the reports are send to.
The example above shows 4 reports defined for this merchant, OrderReport through email for
production, OrderReport though http for test, TransferReport in XML format through e-mail in production
and a TransferReport in XML format through email in test.
The current settings can be edited by selecting the preferred settings from the pull down lists, filling out
the correct address(es) in the address field, selecting 'active' or 'inactive' and clicking on the 'save'
button.
Please note that you can only save the settings of one report at a time.
6.1.4.6 Stylesheet
The stylesheet determines the format of the reports that are sent out.
OrderReport
HTML order report
All information in HTML format
Version 1 order report (deprecated)
This version is only available because some
existing customers' systems require this format.
New merchants are advised to use another
stylesheet.
XML order report
All information in XML format
HTML order report w/BackOffice code
All information in HTML format including the
backOfficeCode. For more information about
the backOfficeCode see section 7.1 of the
Implementation Manual.
Version 1 order report w/BackOffice code
(deprecated)
stylesheet. For more information about the
backOfficeCode see section 7.1 of the
2/12/03
- 25
-
Transfer Report
HTML transfer report
All information in HTML
Version 1 transfer report (deprecated)
stylesheet.
Excel transfer report
This format is comma-tab
importing into Microsoft Excel.
HTML transfer report without regular
payments
This report will only show exceptions, no settled
transactions, only charge-backs, refunds, etc.
HTML transfer
overview
This report will only show the management
summary.
report
only
showing
separated
for
XML transfer report
All information in XML format
HTML transfer report w/BackOffice code
All information in HTML format including the
backOfficeCode. For more information about
the backOfficeCode see section 7.1 of the
Version 1 transfer report w/BackOffice
code (deprecated)
stylesheet. For more information about the
backOfficeCode see section 7.1 of the
Comma
separated
w/BackOffice code
report
This is a comma separated report in TXT
format.
Capture report (for selected merchants
only)
Though merchants can select these reports in
the merchant interface, they can only be
activated by Bibit.
XML capture report
All capture information in XML format
HTML capture report (C accounts)
Capture report in HTML format for 'capture only'
accounts.
HTML capture report (M, S accounts)
Capture report in HTML format for all other
accounts.
TEXT capture report (C accounts)
Capture report in XML format for 'capture only'
accounts.
TEXT capture report (M, S accounts)
Capture report in XML format for all other
accounts.
textual
2/12/03
- 26
-
6.1.4.7 Adding reports
The merchant can add new reports in the 'Insert a new report type' section of the screen. First choose
the environment (production or test), the report (order, capture or transfer report), the format (stylesheet),
fill out the address the report has to be sent to (e-mail address or url), select whether or not the report
should actually be sent (active or inactive) and click 'save'.
6.1.5
Risk Management Module page
When the merchant has subscribed to the Risk Management Module he can change the settings in this
page.
Risk Score Editor
Current risk limit: 100
#
Description
Default score Your Score
1
Similarity of issuer country and IP country
2
Creditcard referral list check
100
100
3
Analysis of recent session actions of this shopper
100
100
4
IP address from high risk country
100
75
5
The number of payment attempts during the session
50
50
6
The number of cards used during the session
100
100
7
Cardnumber ranges used during the session
100
100
8
Email address referral list check
100
100
9
Cardholdername referral list check
50
50
10
The cardholder name contains slang
50
50
11
The issuer country is blocked
100
50
40
40
'Current risk limit: 100' indicates that transactions that score 100 or more during risk assessment will
automatically be blocked by the system. The numbers printed in bold are the scores Bibit advises for that
particular check. Bibit's advice for check number 4 'IP address from high risk country' is 100 points, in
this example the merchant has changed the score to 50.
When clicking on the yellow pencil icon ( ) next to check number 4 the merchant can change the list of
high risk countries. Some countries cannot be removed as the risks for transactions originating from
those countries is deemed to high. These countries are: Algeria, Argentina, Belarus, Bulgaria, Indonesia,
Lithuania, Macedonia, Nigeria, Philippines, Romania, Russian Federation, Ukraine and Yugoslavia.
To add countries to the "issuer country is blocked" list; please open an incident in the support interface,
http://support.bibit.com.
2/12/03
- 27
-
For more information about each individual check, click on the name of the check in the 'risk
management module page'. More information about risk assessment and management can be found our
white paper 'Risk Management' on our documentation website: http://documentation.bibit.com.
6.1.6
Dispute Management page
When Bibit receives an Information Request, a card dispute notification is emailed to the Merchant and
the payment in question is listed in the DM screen, with status INFORMATION_REQUESTED.
The e-mail will state the following:
Dear Merchant,
One of your customers has disputed a transaction with OrderCode:
'DEMO1027597733596'
This dispute may end in a
Charge-back. To avoid this from happening, please log on to the Merchant
Interface, select 'dispute management', click on the status line of the disputed
order(s) and fill out all relevant order information.
Make sure to include at least the following:
-complete invoice, including your shop name, customer name and delivery address
-proof of delivery, with customer signature when available
-any additional information you have to disprove the dispute
You have the possibility of attaching a file. If you wish to attach multiple files,
please compress these files into one zip file before attaching it.
When done please click on the submit button to send the information to the Financial
Institution.
with kind regards,
Bibit Support
To avoid a possible charge back the merchant should follow the instructions in the e-mail.
The transaction mentioned in the e-mail will appear in the 'dispute management' page of the merchant
interface. The disputed payments are ranked by most recent status update. The first four columns
(Order Code, Last update, Amount and Status) contain filters to accommodate tracing a particular
payment. All disputed payments remain in the DM screen for a maximum of 7 days since their last status
change. This way, the Merchant has a complete overview of all payments currently under dispute for his
account.
N.B. Most acquirers only allow a very limited time frame, typically one week, for responding to such an
Information Request! If no information is supplied within that period, a chargeback inevitably follows.
Once the counter information is submitted, a refresh of the DM screen will move this payment to the top
of the list and will update its status to INFORMATION_SUPPLIED. Clicking on an X in the IS column will
display the information that was submitted for that payment.
Order Code
Last update
DEMO108847262489 06/02/2003 - 09:43
Amount
EUR 1,00
Current Status
Risk IR IS CB
INFORMATION_REQUESTED 0
X
-
-
Clicking on the X in the IR column will open a screen in which the Merchant can submit their information
to counter the shopper's chargeback request. This screen also includes the Merchant email address the
card dispute notification was sent to.
This information to counter the chargeback request should include an invoice of the transaction, including
all address details of both merchant and shopper, proof of delivery, preferably signed by the shopper and
any other information that can settle the dispute. The best information is any information that can proof
the shopper and the card holder are one and the same person.
2/12/03
- 28
-
Many acquirers will not notify Bibit if they decide NOT to execute a chargeback. In those cases, the
payment remains in IS and gradually slide to the bottom of the list until it is automatically removed after 7
days.
CHARGED_BACK is the final status currently supported by the DM functionality. Support for Second
presentments is still under development.
Charged back payments are automatically removed from the DM screen 7 days after they reached this
status.
Some acquirers will skip the Information Request altogether and will execute a chargeback immediately.
That's why some payments will only show an X in the CB column.
Clicking on the X in either the IS or the CB column will reveal a 'Remove' button, which the Merchant can
use to manually remove either IS or CB payments from the overview even before the 7 days have
passed.
Doing so will restrict the DM screen to showing only the 'actionable' disputed payments.
N.B. Removing an IS payment in no way influences the acquirer's decision making process, i.e. the
payment will reappear on the list once a chargeback is executed, or in case an additional Information
Request follows.
2/12/03
- 29
-
When the merchant clicks the 'browse' button a 'choose file' window will open and the merchant can
select the file he wants to send to the financial institution. This can only be ONE file. This file can contain
scanned images in jpeg format and Microsoft Word documents. When the merchant wants to send more
that one document the documents have to be archived in a .zip file. More information about 'zipping' a
collection of files on the Microsoft Windows environment can be found at http://www.winzip.com.
Along with the file the merchant can enter free text to accompany the file.
Please note that this functionality can only be used ONCE per disputed transaction. The merchant
should also realise that simply stating that the goods have been delivered in the free text box doesn't
persuade the financial institutions to disagree with their customer, the shopper.
All messages to the acquirers should be in English!
When the merchant sends this message it will be received by an automated process on the Bibit
Payment Service, specific information about the transaction that is not available to the merchant will be
added to the message, the entire message will be encrypted and is send to the appropriate address
within the financial network. This process is completely automated; no Bibit staff will actually see any of
the messages that are sent to the acquirers.
6.1.6.1 Examples of useless 'proof'.
The examples below are real life examples of the 'proof' some merchants send as a response to an
'information request'. These are examples of situations where the merchant HAS NOT provided any
information that is helpful in persuading the financial institution not to charge-back the full amount of the
transaction.
Merchants should realise that all information provided is sent directly to the financial institutions without
any intervention of Bibit staff.
·
Left message for [name removed] 7/23/2002 for more information on dispute. What was her reason
for the dispute? Waiting for her to return phone call
·
For this order we have proof of delivery. The was delivered on the 10-05-2002.
2/12/03
- 30
-
·
Called [company name removed] 7/22/2002 and the receptionist stated that [name removed] no
longer works for the company. And she could not verify the charge
·
Dear Bibit Support Department,
We have received your dispute request concerning a payment for a congress. We have to inform
you that we do not agree with the dispute, due to the fact the specific person attended the congress
which we organised in Florence in June. If the cardholder still has a problem with the payment, he
needs to get in touch with [company name removed], telephone: [phone number removed]. We hope
we have informed you accordingly, With kind regards,
·
Can you please tell me why this order has Information Requested as the status.
·
Why does this client want a chrage back while his ad is already running for more then 3 months
now. In our terms and conditions (see below) at [url removed] clearly stands that now refund is given
after purchasing an ad (especially not after three months running). So we do not agree with a charge
back. Let him explain why and we might come to a solution.
These are examples of messages that do not contain any proof whatsoever. The financial institutions will
not get back to the merchant, this is a one way communication where the merchant is requested to
deliver proof.
6.1.6.2 Examples of good 'proof'.
Below are some good examples of proof.
·
This order was processed correctly, we sent the products on 07-05-2002. The attachment shows the
register-number under which the package has been sent with the requested address and customer
details.
·
Please find attached the customer invoice and the signed proof of delivery. All ordered products
have been delivered. No customer complaints received.
·
As the products ordered have been downloaded through the internet, we cannot provide signed
proof of delivery. We have however attached the full customer details, invoice and ip-address the
product has been downloaded from.
All these messages had files attached that contain all information that helps the financial institutions
decide whether the amount will be charged back or not. When Signed proof of delivery, delivery
addresses, customer details, etc are attached the financial institutions can crosscheck this information
with the details they have about their cardholders.
2/12/03
- 31
-
7 The Bibit invoice
The costs for the use of the Bibit Payment Service is billed through monthly invoices. The invoices show the
monthly costs of all the services that are delivered to the merchant by Bibit. Costs of the Financial institutions are
automatically deducted from the batches that are transferred to the merchants.
The invoices for all Dutch merchants are deducted from the merchant's bank account automatically, the invoices
are send for administrative purposes.
BIBIT B.V.
Kosterijland 20
NL 3981 AJ Bunnik
The Netherlands
MERCHANT Ltd.
PO Box 1000
2536 KL MerchantCity
The Netherlands
Bibit Bankdetails will displayed here
Invoice
Date 17-7-2002
Merchantcode MERCHANTCODE Invoice number 123456
Number
Currency
Rate
Amount
Internet Payment Services
1
EUR
149.00
149.00
Risk Management
1
EUR
30.00
30.00
Callcenter add-on
0
EUR
0.00
0.00
Processed Payments
25623
EUR
0.35
8968.05
Risk management
25623
EUR
0.25
6405.75
Chargebacks
0
EUR
12.00
0.00
Non automated payments
0
EUR
0.90
0.00
Refunds
1
EUR
2.50
2.50
Subscription July 2002
Transactions June 2002
VAT: 0% over EUR 15373.80
0.00
Total EUR
15373.80
We kindly request you to transfer the total amount within 14 days of invoice. Please quote your Merchantcode
and Invoice number when requesting payments to be made.
In case of any questions do not hesitate to contact us, tel: +31 30 63 65 815 or e-mail: [email protected]
BIBIT B.V. is established in Bunnik, The Netherlands and registered at the Chamber of Commerce in Utrecht no. 30.150.865
VAT number: NL 80.71.53.047.B.01
2/12/03
- 32
-
The monthly subscription fees are charged one month in advance and can be found in the 'subscription' part of
the invoice. The 'transactions' part of the invoice contains the fees for the transactions and other fees which are
charged for the previous month.
·
Processed payments is the total number of payments processed in that month.
·
Risk Management is the total number of payments that have been processed by the Risk Management
Module.
·
Chargebacks is the total number of chargebacks received by the merchant during this month.
·
Non automated payments is the total number of off line payment methods processed during this month.
·
Refunds is the total number of refunds processed this month.
When the invoice can not be paid for some reason, not even after several attempts, the invoices will be deducted
from the transferred money and will be specified in the transfer report.
8 Frequently Asked Questions
If you have questions that weren't answered by this manual you can log on to the support website at
http://support.bibit.com. You can search our database with answers in 'find answers'. When there is no answer to
your question present in the database (even after rephrasing your question) you can open an incident for our
support department in 'ask us'. You will be presented with suggested answers before the question is submitted.
Below you will find a small collection of frequently asked questions.
8.1
When to expect payments from Bibit?
Once the payment flow has started (it takes about three weeks for some credit cards to be fully processed) the
merchant can expect weekly payments from Bibit.
As not all payment methods can be automated to the same extent small fluctuations in the pay out frequency may
occur. This also depends on other links within the chain of financial institutions used to process payments.
It is important to realise that some payment methods can be settled within a smaller timeframe than other
payment methods, this is due to the nature of the payment method. Where one payment done on the same day as
another may be settled within 3 days, the other payment may be settled three weeks later.
8.2
What is the deposit for and when can I expect it back?
The deposit is used to safeguard Bibit from financial risks. These can occur when the merchants receives a
(large) number of charge-backs and there are not enough transactions in process for this merchant. When the
contract is terminated there is still a risk of charge-backs, this time with no new transactions coming through.
Charge-backs that are received after the termination of the contract will be paid from the deposit.
The merchant can expect the deposit back after the charge-back term for the most recent credit card transaction
is expired.
2/12/03
- 33
-
8.3
How can I do a refund?
SSL payment methods can be refunded through the merchant interface or by sending a orderModification XML
message to the Bibit Payment Service. This is described in section 6.1.2.2 of this manual. More information about
orderModification messages can be found in the Implementation Manual, section 9.2. When the 'refund' button
does not appear in the payment details, the payment can not or not yet be refunded. Only payments that have
reached or passed the status 'captured' can be refunded. Or the payment method used can not be refunded
through the merchant interface or orderModification messages. In that case the merchant should contact Bibit
through the support interface which can be found at http://support.bibit.com.
8.4
How long does it take to fully process a refund?
Refund requests sent to the Bibit Payment Service by merchants are processed by the Bibit Payment Service in
batches every 90 minutes and sent to the financial network. The merchant has to realise that although the Bibit
Payment Service has processed the refund, the processing of the refund by the financial institutions can take up
to 6 weeks. It is therefore advised that the merchant lets his shopper know it will take a little time before he can
expect the money back on their card/bank account.
8.5
How can I cancel a payment?
As long as a payment hasn't passed the 'authorised' status the payment, or rather the authorisation can be
cancelled. This can be done through the merchant interface as described in section 6.1.2.2 of this manual. Or by
sending an orderModification XML message to the Bibit Payment Service as described in section 9.1of the
8.6
Why did I get a charge-back?
Charge-backs can occur when a shopper doesn't recognise the description in his card or bank statement. The
issuing banks don't always put the merchant's name on the statement (except when the merchant has his own
accounts with the acquirers). The shopper may believe that he never ordered goods and asks his card company
or bank for his money back. The shopper may also ask the bank or card company for more information. When
Bibit receives such requests the merchant will be informed. The payments where information is requested will
reach status 'Information Requested' and will show up in the dispute management tool of the merchant interface,
see section 6.16 of this manual. When the merchant doesn't provide information that shows the transaction was
correctly booked on the cardholder's card or no information at all, the card company or bank may decide to take it
to the next level and charge-back the money for the transaction.
There sometimes are cases of credit card fraud when a shopper uses someone else's credit card number without
permission of the cardholder. When the cardholder discovers that unauthorised transactions have been made on
his card he may demand his money back from the card company or the bank.
The card companies tend to believe the cardholder in all cases where the merchant cannot provide ample proof.
Some other payment methods, like incasso or ELV, may reach charge back when the banks discover that the
shopper didn't have enough funds in his bank account.
2/12/03
- 34
-
8.7
How can I prevent charge-backs?
Most charge-backs can be prevented by a few very simple measures. Letting the shopper know the transaction is
processed by Bibit and Bibit's name may appear on the statement, will avoid confusion on the shopper's end.
Check as many details about the shopper's origin as practically possible (the Risk Management Module can assist
the merchant in this), look for signs of possible fraud and when in doubt contact the shopper (more information
about this can be found in our whitepaper 'Riskmanagement' which can be downloaded from
http://documentation.bibit.com). Make sure your shopper can contact you with questions and have a properly
working return policy in place in case of complaints or damaged goods.
Good communication between shopper and merchant can prevent a lot of charge-backs.
8.8
Why doesn't this order have a payment status?
As explained in section 4.1 of the Implementation Manual there is a difference between orders and payments. A
payment is an order that has reached a payment status, be it 'refused', 'settled' or any other possible payment
status. An order is created just before the shopper is directed to the secured environment of the Bibit Payment
Service. Once the shopper is redirected to the payment selection page he may change his mind and leave the
process. This way there will be an order but no payment. In the case of a bank transfer, the shopper may have
transferred the incorrect amount to Bibit, used no or an incorrect reference number or transferred an incorrect
amount. In all three cases the order may not receive a payment; in the last two cases the money will be send back
to the shopper's bank account.
8.9
How can I increase the maximum transaction amount?
Each type of contract has it's own fixed maximum transaction amount. The maximum transaction amount for a
Standard Service contract is Euro 450,- and for a Plus Service contract it is Euro 1000,- or their ForEx equivalent.
Merchants with a Standard Service contract who want to increase their maximum transaction amount can change
their contract to a Plus Service contract. Merchants with a Plus Service contract who want to increase their
maximum transaction amount can do so under certain circumstances by contacting the Bibit Sales department. In
most cases the deposit will be increased.
2/12/03
- 35
-
Index
acquirer............................................................... 4, 5
Acquirer ................................................................. 3
Amount......................................6, 14, 15, 16, 17, 18
Authorisation.......................................................... 4
AUTO................................................................... 13
backOfficeCode.............................................. 25, 26
Batch ...................................................................... 4
Batches ................................................................. 12
Capture..........................................4, 5, 6, 17, 19, 26
capture delay .............................................. 5, 12, 19
capture report ................................................. 10, 26
Card holder name ................................................. 16
Charge back ........................................................... 4
charged-back .......................................................... 7
Confirmation messages .......................................... 6
Continue Button ........................................... 17, 19
Cost ........................................................................ 7
Creation date ........................................................ 14
Currency..................................................... 6, 17, 18
Date ............................................................ 6, 16, 18
Deposit ..................................................... 12, 17, 18
Dispute Management ................................... 3, 4, 28
e-mail feature ....................................................... 22
Environment properties..................................... 20
filters .................................................................... 14
Financial Institutions ............................................. 3
HTTPS Proxy....................................................... 19
Internal order id.............................................. 15, 17
Issuing bank ........................................................... 3
Last event ............................................................. 14
Last update ........................................................... 16
Management Summary .......................................... 7
maximum transaction amount............................ 34
Maximum transaction amount.......................... 19
merchant channels .......................................... 19, 24
Merchant Interface ................................... 3, 4, 5, 12
Method ......................................................... 6, 7, 24
Miscellaneous transactions..................................... 7
Net.......................................................................... 7
2/12/03
NO REFERENCE.................................................13
Open batches.........................................................13
Order.......................................................4, 6, 14, 16
order code .............................6, 7, 14, 15, 16, 17, 23
order report .................................................6, 25, 31
OrderCode.....................................................6, 7, 28
OrderContent ..................................................15, 17
partial capture .......................................................16
Password........................................................17, 18
payment.................................................................32
Payment . 3, 4, 5, 6, 7, 12, 14, 15, 16, 17, 18, 19, 20,
22, 23, 24, 25, 28
payment details .....................................5, 15, 16, 17
payment reference...........................................15, 17
Payments...............................................7, 14, 16, 21
Payments settled .....................................................7
Reconciliation .........................................................3
refund ................................................4, 7, 15, 16, 30
Refund .........................................................4, 15, 16
Refusal ....................................................................4
Risk ...................................................3, 4, 14, 27, 28
Risk Management Module.......................3, 4, 14, 27
Settlement ............................................................18
Shop name .....................................................17, 18
Shop URL ............................................................18
Status.....................................................6, 12, 16, 23
Stichting Derdegelden Bibit Internet Payments ..3, 5
Stichting Trusted Third Party Bibit Internet
Payments.............................................................3
Stylesheet ..............................................................25
Sum .........................................................................6
To be received from Financial Institution .............12
To be transferred to Merchant...............................12
Transfer Details.......................................................7
transfer report..................................7, 26, 27, 33, 34
Transfer reports.......................................................6
Transferred to Merchant .......................................12
wildcard ................................................................15
XML password..............................................18, 22
- 36
-

Bibit Administrative Manual

Transcription

Similar documents

PCI Compliance Instructions

PCI Compliance Instructions

Private Label Card Management Software

Natalie Merchant - Charlotte Symphony Orchestra

Merchant Incentive Program

USA Epay Gateway Build Instructions You will be provided a user

6/2 Merchant Building, 27 Watson Street,Merchant City, Glasgow

prospective merchant info sheet - corporate

Optimal Payments Extension - Demac Media