Sandbox: Difference between revisions

From Barion Documentation
Jump to navigation Jump to search
VisualWikitext
m (→‎Test cards: replaced reference to v2 GetPaymentState with v4 PaymentState)
(replaced old content with rewritten and approved content. to-do: links)
Line 6: Line 6:
|}
|}


=Sandbox server=
Barion Sandbox is a non-PCI DSS compliant test server that provides a playground environment for Barion developers, that’s identical to the production server in terms of Barion API support.
Although Barion payments are very easy to integrate, we strongly advise all developers to use our Sandbox server for development and testing before going live.  


There are numerous advantages of using the sandbox server for testing:
The point of Barion Sandbox is to simulate Barion Smart Gateway features, and Barion API endpoint functionality on the live Barion server environment, so you can try out your custom or plugin-based webshop integration without real-world financial consequences.
*Sandbox is always available, you can even start working at night or during weekends. However, keep in mind that except for the Facebook group, [[Support|support]] is only available during working hours.
*Sandbox is totally self-service, no contract or NDA needed to use it
*No transaction fees are spent during development and testing
*The live and the sandbox systems are completely separated, so you can use the same email address in both (careful, do not mix up the enviroments).


=Limitations in functionality=
<blockquote>Note that because the production server and Barion Sandbox are separate environments, you can use the same email address as Barion ID on both.
The sandbox server is a copy of the live Barion servers, with some minor differences:


*From the developer perspective, the only difference is the URL
This also means that you can’t port the Barion Wallet you’ve created in the Barion Sandbox to the production environment – you explicitly need to create a new Barion Wallet in production.
*No real money in the sandbox, all transactions are using "test" money that has no real value
</blockquote>
*Since the sandbox is not using real money, withdrawal to bank accounts is not possible
<span id="differences-between-production-and-barion-sandbox"></span>
*Real bank cards do not work, we provide a test card
== Differences between production and Barion Sandbox ==
*Top-up is only possible with a test card
*The servers are of smaller capacity
*Simple SSL certificates are used
*Sandbox servers are updated regularly without notice (we are doing our best not to lose any data)


[[file:live-sandbox.png|1000px]]
Barion Sandbox differs from the production environment in the following:


=Registering accounts=
* the URL has “test” added:
Just as in the live server, a simple online form is needed to register a Barion account. Each merchant needs a Barion account, or Wallet, as we call it. Payments are credited to this account immediately after payment.
** <code>secure.test.barion.com</code>
'''Note''': Always double-check your environment before calling support.
** <code>api.test.barion.com</code>
* a standard HTTPS certificate is used as opposed to Extended Validation (EV) used on the production server
* transactions are made in nominal funds:
** outgoing transfers to bank accounts aren’t supported
** only the dedicated test bank cards are supported for payments and adding money to your Barion Wallet balance
* test cards that trigger various pre-set payment process responses are supported
* 3D-S authentication isn’t performed when using test cards
* actual bank cards aren’t guaranteed to work
* the [[05-api-reference/01-payment-resource/00-payment-resource-objects/07-purchase-information#recurring-frequency|RecurringFrequency property]] of subsequent payments in a subscription payment scenario isn’t checked
* [[01-payments/02-basic-payment-concepts/03-callback-mechanism|callbacks for payment status changes]] are sent [[01-payments/02-basic-payment-concepts/03-callback-mechanism#sandbox-barion-api-ip-address|from a different IP address]]
* Barion shops are approved automatically – you don’t have to [[01-payments/01-quickstart-make-a-test-payment-online/02-onboarding|go through onboarding]] when setting up a test Barion shop
* no KYC procedures are in place:
** there’s no need or indeed way to verify your identity as the owner of a Barion Wallet,
** there aren’t any (transfer, balance, or payment) limits on Barion Wallets in the Barion Sandbox
** no data you enter during registration (email address, shop details, etc.) is checked or verified
* the Barion Smart Gateway is displayed with a warning ribbon
* token payment scenarios are enabled by default
* [[03-barion-bridge/00-barion-bridge|Barion Bridge]] is enabled by default
* there’s no SLA for any downtime, or assurance for any potential data loss resulting from a server update


https://secure.test.barion.com/Registration
<span id="using-the-barion-sandbox"></span>
== Using the Barion Sandbox ==


This URL is identical to https://test.barion.com/Registration, the word "secure" can be omitted.
Make dummy purchases in your Barion shop on the Barion Sandbox server using test card data that always returns the same payment process results to test whether your Barion integration reacts properly to various payment outcomes.


=Opening a shop=
<span id="test-cards"></span>
Opening a shop in the sandbox is the same as opening one in the live server. The only difference is that the sandbox is wired to automatically approve all changes, while the live server requires a human compliance officer to approve the shop.
=== Test cards ===
'''You still have to <u>send the shop for approval</u> using the shop creating/editing form or the link in the shop grid.'''
Also, prepare for questions and some minor paperwork when switching from sandbox to live.


=API URL=
Each of the <code>ProcessResult</code> property value options in the <code>FundingInformation</code> object returned by the payment state endpoint has a dedicated test card that reliably triggers it.
The base URL for the Barion API is the same as the live one, with the word "test" added.


https://api.test.barion.com
All test cards accept any future date as expiration date, and any 3-digit number as CVC code.


=HTTPS and Certificates=
{|
All communication with the Barion system must be done using TLS v1.2 / 1.3 - earlier encryption standards (SSLv3, TLS1.0, etc.) are not allowed. You can test your solution on the Sandbox server.
|Successful
|4444 8888 8888 5559
|-
|ProblemWithCard
|4444 8888 8888 4446
|-
|LowFunds
|4444 8888 8888 9999
|-
|LostOrStolenCard
|4444 8888 8888 1111
|-
|Declined
|4444 8888 8888 3331
|-
|FraudulentTransaction
|4444 8888 8888 6664
|-
|CardSystemError
|4444 8888 8888 7779
|-
|ScaSoftDeclined
|4444 8888 8888 0006
|}


Our sandbox server is using more economical certificates, than the live server. A standard HTTPS certificate is used, instead of Extended Validation (EV), and a less well-known brand has been chosen. This does not affect security and development, and applies only to the sandbox.
<span id="using-the-barion-mobile-app-in-sandbox-mode"></span>
=== Using the Barion mobile app in Sandbox mode ===


=Test cards=
Add “test#” in front of your Barion ID email address when logging in to the Barion mobile app to make the app connect to the Sandbox server instead of the production one: <code>test#[email protected]</code>


The sandbox server is connected to a card acquirer, so all transactions using the test card reach out to that server. This can cause a variation in card processing time. If you make several payments to a merchant, the account can reach a balance where another level of KYC is required, and the account is temporarily suspended. Suspended accounts can initiate payments, but can not send or withdraw money. Drop a mail to support if run into this, or cannot avoid it.
The Barion mobile app displays a green ribbon across the top of the device screen to indicate that it’s currently connected to the Barion Sandbox server.
<br>Each test card is represented with a different value in the response of <code>PaymentState</code> (see <code>FundingInformation</code> -> <code>ProcessResult</code>)


[[file:Test-card2.png]]
<span id="related-links"></span>
<br>
== Related links ==
'''CARD 1''' - SUCCEED - the card transaction was successful
*BIN: '''4444 8888 8888 5559'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''


PaymentState result: <code>Successful</code>
When you’ve made sure that your Barion shop’s website handles all the necessary user interactions and API responses, switch to the production environment.
 
<br>
'''CARD 2''' - FAIL - the card transaction was unsuccessful: card number, CVC or/and expiry is wrong.
*BIN: '''4444 8888 8888 4446'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>ProblemWithCard</code>
 
<br>
'''CARD 3''' - FAIL - the card transaction was unsuccessful due to insufficient funds
*BIN: '''4444 8888 8888 9999'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>LowFunds</code>
 
<br>
'''CARD 4''' - FAIL - the credit card has been reported lost or stolen
*BIN: '''4444 8888 8888 1111'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>LostOrStolenCard</code>
 
<br>
'''CARD 5''' - FAIL - the payment card was declined by the acquirer
*BIN: '''4444 8888 8888 3331'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>Declined</code>
 
<br>
'''CARD 6''' - FAIL - Due to potentially fraudulent transaction, the monitoring system declined the transaction
*BIN: '''4444 8888 8888 6664'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>FraudulentTransaction</code>
 
<br>
'''CARD 7''' - FAIL - the card transaction failed due to the card system
*BIN: '''4444 8888 8888 7779'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
PaymentState result: <code>CardSystemError</code>
 
<br>
'''CARD 8''' - FAIL - the payment card did not support SCA at the time of the transaction
*BIN: '''4444 8888 8888 0006'''
*Expiration date: '''any future date'''
*CVC: '''any 3-digit number'''
 
[[3DS_FAQ#What_is_a_soft_decline.3F|What is a soft decline?]]<br/>
'''If you are not sending an exemption the charge will succeed.'''<br/>
 
PaymentState result: <code>ScaSoftDeclined</code>
 
=Payment GUI=
The payment GUI in the sandbox server is the same as in the live environment, with the following exceptions:
*A black bar is present at the top, displaying the "sandbox server" message
*The URL has the word "test" in it
*It only accepts test cards, no real cards can be used
*All payments are with "test" money, not real money
 
[[file:Sandbox-payment-gui.PNG|600px]]
 
 
{{NotificationBox|title=IMPORTANT|text=Confirmation emails are actually sent out in the Sandbox environment as well, so DO NOT use any real email address that does not belong to you. Use your own personal or development email address, or if you do not care about the email itself, use the @example.com email domain.
|color=#1993c7}}
 
=Using the Barion Web App in Sandbox mode=
You can log into the Barion Web App on the same URL, with the word "test" added. A black bar is shown on top of each screen to help differentiate it from the live server.
https://secure.test.barion.com/
 
This URL is identical to https://test.barion.com/, the word "secure" can be omitted.
 
= Using the Barion Mobile App in Sandbox mode =
You can also use the Barion Mobile App with the sandbox server by entering <tt>test#</tt> before the email address when logging into the app. The title bar of the app turns green to help differentiate it from live accounts. You can download the app from Google Play or from the App Store.
 
<source lang="html4strict">
test#youremail@example.com
</source>

Revision as of 09:52, 5 August 2024

Setting up the Sandbox environment and testing payments

Barion Sandbox is a non-PCI DSS compliant test server that provides a playground environment for Barion developers, that’s identical to the production server in terms of Barion API support.

The point of Barion Sandbox is to simulate Barion Smart Gateway features, and Barion API endpoint functionality on the live Barion server environment, so you can try out your custom or plugin-based webshop integration without real-world financial consequences.

Note that because the production server and Barion Sandbox are separate environments, you can use the same email address as Barion ID on both.

This also means that you can’t port the Barion Wallet you’ve created in the Barion Sandbox to the production environment – you explicitly need to create a new Barion Wallet in production.

Differences between production and Barion Sandbox

Barion Sandbox differs from the production environment in the following:

  • the URL has “test” added:
    • secure.test.barion.com
    • api.test.barion.com
  • a standard HTTPS certificate is used as opposed to Extended Validation (EV) used on the production server
  • transactions are made in nominal funds:
    • outgoing transfers to bank accounts aren’t supported
    • only the dedicated test bank cards are supported for payments and adding money to your Barion Wallet balance
  • test cards that trigger various pre-set payment process responses are supported
  • 3D-S authentication isn’t performed when using test cards
  • actual bank cards aren’t guaranteed to work
  • the RecurringFrequency property of subsequent payments in a subscription payment scenario isn’t checked
  • callbacks for payment status changes are sent from a different IP address
  • Barion shops are approved automatically – you don’t have to go through onboarding when setting up a test Barion shop
  • no KYC procedures are in place:
    • there’s no need or indeed way to verify your identity as the owner of a Barion Wallet,
    • there aren’t any (transfer, balance, or payment) limits on Barion Wallets in the Barion Sandbox
    • no data you enter during registration (email address, shop details, etc.) is checked or verified
  • the Barion Smart Gateway is displayed with a warning ribbon
  • token payment scenarios are enabled by default
  • Barion Bridge is enabled by default
  • there’s no SLA for any downtime, or assurance for any potential data loss resulting from a server update

Using the Barion Sandbox

Make dummy purchases in your Barion shop on the Barion Sandbox server using test card data that always returns the same payment process results to test whether your Barion integration reacts properly to various payment outcomes.

Test cards

Each of the ProcessResult property value options in the FundingInformation object returned by the payment state endpoint has a dedicated test card that reliably triggers it.

All test cards accept any future date as expiration date, and any 3-digit number as CVC code.

Successful 4444 8888 8888 5559
ProblemWithCard 4444 8888 8888 4446
LowFunds 4444 8888 8888 9999
LostOrStolenCard 4444 8888 8888 1111
Declined 4444 8888 8888 3331
FraudulentTransaction 4444 8888 8888 6664
CardSystemError 4444 8888 8888 7779
ScaSoftDeclined 4444 8888 8888 0006

Using the Barion mobile app in Sandbox mode

Add “test#” in front of your Barion ID email address when logging in to the Barion mobile app to make the app connect to the Sandbox server instead of the production one: test#[email protected]

The Barion mobile app displays a green ribbon across the top of the device screen to indicate that it’s currently connected to the Barion Sandbox server.

Related links

When you’ve made sure that your Barion shop’s website handles all the necessary user interactions and API responses, switch to the production environment.

Retrieved from "https://docs.barion.com/index.php?title=Sandbox&oldid=4523"