Skrill1Tap

Skrill offers a single-click payment service that enables customers to automatically debit transactions from your customer’s Skrill account without the customer having to log in to their account and authorizes each time.

Customers are sent an email notification after each 1-Tap payment and they can view the status of all their Skrill 1-Tap payments in the History section of their Skrill Wallet account.

This payment method works on a subscription model, customer subscribes to a merchant with their Skrill wallet or Card and can make transactions until the subscription is canceled.

Customers can pay using Skrill 1-Tap with any of the following payment methods linked to their Skrill account:

Credit/debit card (Visa and MasterCard)

Skrill account balance

To access this account service, merchants must be onboarded with Skrill's Solution.

The Payments API caters to the following needs for Skrill 1-Tap

  • Payment Instrument: Skrill 1-Tap

  • Payment Method: Card Transactions or Wallet Balance

  • Currencies:

    • Available: EUR, USD, GBP, HKD, SGD, JPY, CAD, AUD, CHF, DKK, SEK, NOK, ILS, MYR, NZD, TRY, AED, MAD, QAR, SAR, TWD, THB, CZK, HUF, BGN, PLN, ISK, INR, KRW, ZAR, RON, HRK, JOD, OMR, RSD, TND, BHD, KWD

    • Banned: AF, CU, ER, IR, IQ, JP, KG, LY, KP, SD, SS, SY

Setup Requirements

For Paysafe to create a test account in the sandbox and production environment, we need the following details.

  • Merchant's Skrill Pay to Email

  • Merchant's Skrill account API/MQI Password

Transaction types

Transaction types: Payments, Refunds, Payouts

Flow Diagrams

Typical Scenarios

Subscription + First Payments Flow

For a new user to consume this service, the below steps are required:

The user will have to log in to their skrill account in which they will provide consent for Subsequent payments without login and complete the first transaction. The merchant is supposed to provide few important parameters which will be used to identify the user in subsequent calls

  • Create a Payment Handle request with the transactionType parameter set to PAYMENT and the paymentType parameter set to SKRILL1TAP.

  • In the skrill1tap object of the request packet, the consumerId should be set to the set to a unique ID of the user which will be used in subsequent calls to identify the user, account and subscription, along with it maxAmount is also passed which puts a limit on the amount of the subsequent transactions.

    • Post: paymenthub/v1/paymenthandles

  • Since the customer has to complete payment and provide consent for subsequent transactions on the Skrill platform by logging in, Paysafe returns a response with the following:

    • The action parameter is set to REDIRECT

    • A payment_redirect link points to Skrill Page redirect URL

    • The status of the Payment Handle will be in INITIATED stage

  • After the user is redirected to payment_redirect on the Skrill page, the user will have to log in and complete the transaction.

  • After the completion of this transaction, the user is redirected to the success or failed page of the merchant, depending upon the status of the transaction.

  • The status of the Payment Handle becomes PAYABLE after a Successful transaction and FAILED if the transaction fails. The merchant gets notified of this status change via a webhook that has been configured.

  • Use the paymentHandleToken returned in the response to process the Payments API request.

    • paymenthub/v1/payments

The user can have multiple subscriptions with the same merchant, each subscription will be identified on the basis of consumerId. The user can see all active subscriptions in their Skrill account along with the maxAmount set and can cancel it anytime. Once the subscription is canceled, all saved information apart from transaction history will be cleared and the user will be considered as new even if the same consumerId is used again.

APIs to use: Payment Handles+ Payments

Subsequent Payments Flow

This flow will be active once the user has subscribed to Skrill 1-tap for the merchant and has completed the first Payment.

The consumerId has to be the same as what was used in the Subscription call otherwise, the user will be considered a new user.

Create a Payment Handle request with the transactionType parameter set to PAYMENT and the paymentType parameter set to SKRILL1TAP.

In the skrill1tap object of the request packet, the consumerId should be set to the set to the unique ID of the user for this subscription that was used in first transaction.

Post : paymenthub/v1/paymenthandles

There will be no redirection

The status of the Payment Handle becomes PAYABLE after a Successful transaction and FAILED if the transaction fails. The merchant gets notified of this status change via a webhook that has been configured.

Use the paymentHandleToken returned in the response to process the Payments API request.

paymenthub/v1/payments

APIs to use: Payment Handles+ Payments

Withdrawal/Payout Flow

This flow will be active once the user has subscribed to Skrill 1-tap for the merchant and has completed the first Payment.

The consumerId has to be the same as what was used in the Subscription call otherwise, the user will be considered a new user.

Create a Payment Handle request with the transactionType parameter set to STANDALONE_CREDIT and the paymentType parameter set to SKRILL1TAP.

In the skrill1tap object of the request packet, the consumerId should be set to the set to the unique ID of the user for this subscription that was used in the first transaction, some extra parameters are needed as this transaction is for withdrawal.

Post : paymenthub/v1/paymenthandles

There will be no redirection

The status of the Payment Handle becomes PAYABLE after a Successful transaction and FAILED if the transaction fails. The merchant gets notified of this status change via a webhook that has been configured.

Use the paymentHandleToken returned in the response to process the Standalone Credits API request.

paymenthub/v1/standalonecredits

APIs to use: Payment Handles+ Standalone Credits

Refunds

Refunds can only be triggered once payment is completed and settled and the transaction ID of the Payment is used.

Once the Payment is done i.e. the status is COMPLETED in the response of Payments information the refund can be initiated using the payment ID.

Create a refund request with the Refunds API

Post: /paymenthub/v1/settlements/{paymentId}/refunds

The request will take an amount, which could be equal to what was in the Payments, or could be a partial refund with an amount lower than what was in the Payments.

Multiple partial refunds can be initiated till the total sum of the amounts is lesser than the initial payment amount.

The Response will contain the details of the payment done and a unique identifier that could be used to refer to each individual refund, either partial or full.

The status of the refund will initially be in the PENDING state and will move to COMPLETED once the refund is processed to the user's Account, at each step a webhook will be triggered to the merchant.

APIs to use: Refunds API

API Contracts

Payments

Payments PaymentHandle API Request:

Payments PaymentHandle API Response:

Payments API Request:

Payments API Response:

To know more about each parameter, you can visit Payments.

Standalone Credits/ Withdrawals

Standalone Credits PaymentHandle API Request:

Standalone Credits PaymentHandle API Response:

Standalone Credits API Request:

Standalone Credits API Response:

Refunds

Refunds API Request:

Refunds API Response:

Appendix

Webhooks:

Payment Handle

  1. PAYMENT_HANDLE_PAYABLE - This webhook signifies that the Payment Handle token created for the required purpose can now be executed and the preliminary requirements are completed, and the next API call with the payment handle can be done.

  2. PAYMENT_HANDLE_PROCESSING - This webhook is triggered when the user is successfully redirected to the Payment Platform page and operation has started for the payment by the user.

  3. PAYMENT_HANDLE_COMPLETED - This webhook is triggered when the process of the payment handle token is completed after triggering the next API i.e. Payments or Standalone Credit API.

  4. PAYMENT_HANDLE_EXPIRED - This webhook is triggered when the next step is not initiated after the payment handle is created within the given time frame, the duration can be seen in the response to/paymenthub/v1/paymenthandles API under the tag timeToLiveSeconds.

  5. PAYMENT_HANDLE_FAILED

Payments

  1. PAYMENT_PROCESSING: The payment is in progress. In some cases, there might be delays due to an action pending by the customer or the merchant.

  2. PAYMENT_COMPLETED/SETTLEMENT_COMPLETED - The payment was completed successfully.

  3. PAYMENT_FAILED - This webhook is triggered when the Payment fails during the process.

Standalone Credits/Withdrawal

  1. SA_CREDIT_FAILED - This webhook is triggered in case the transaction was initially completed and later failed due to some settlement error.

  2. SA_CREDIT_CANCELLED - This webhook is triggered when the transaction was canceled after it was completed

  3. SA_CREDIT_ERRORED - This webhook is used when there is a technical error during the initiation of a transaction.

  4. SA_CREDIT_PENDING - This webhook is triggered when the withdrawal has been initiated but due to any delays in the processing, the actual money transfer has not happened immediately.

Refunds

  1. REFUND_FAILED - This webhook is triggered when the refund is initiated but failed due to a functional error for e.g. Refund amount is more than the Payment amount.

  2. REFUND_COMPLETED - This webhook is triggered when the refund has been successfully transferred from the merchant account to the user's account

  3. REFUND_PENDING - This webhook is triggered when the withdrawal has been initiated but due to any delays in the processing, the actual money transfer has not happened immediately.

Error Codes of Skrill 1-Tap

Error Description
SESSION_EXPIRED Session has expired. Session IDs are only valid for 15 minutes.
CUSTOMER_IS_LOCKED The customer's account is locked for outgoing payments.
BALANCE_NOT_ENOUGH The customer's account balance is insufficient.
RECIPIENT_LIMIT_EXCEEDED The customer's account limits are not sufficient.
CARD_FAILED The customer's credit or debit card failed.
REQUEST_FAILED Generic response for transaction failing for any other reason.
ONDEMAND_CANCELLED The customer has cancelled this Skrill 1-Tap payment.
ONDEMAND_INVALID The Skrill 1-Tap payment requested does not exist.
MAX_REQ_REACHED Too many failed Skrill 1-Tap payment requests to the API. For security reasons, only two failed attempts per user per 24 hours are allowed.
MAX_AMOUNT_REACHED The payment amount is greater than the maximum amount configured when 1-Tap payments were setup for this user.
INVALID_OR_MISSING_ACTION Wrong action or no action is provided.
LOGIN_INVALID Email address and/or password were not provided.
INVALID_REC_PAYMENT_ID Invalid recurring payment ID is submitted by the merchant.
MISSING_EMAIL Provide registered email address of merchant account.
MISSING_PASSWORD Provide correct API/MQI password.
MISSING_AMOUNT Provide amount you wish to send.
MISSING_CURRENCY Provide currency you wish to send.
MISSING_BNF_EMAIL Provide email address of the beneficiary.
MISSING_SUBJECT Provide subject of the payment.
MISSING_NOTE Provide notes for the payment.
Unauthorised/ Cannot log in Authentication is required and has failed or has not yet been provided.
Payment Required Reserved for future use.
Forbidden The request was a valid request, but the server is refusing to respond to it. For example, the provided credentials were successfully authenticated but do not grant the client permission to access the resource.
Not Found The requested resource could not be found.
Method not Allowed A request was made of a resource using a request method not supported. For example, using GET on a method which requires data to be presented via POST.

The table below contains all possible values of the ‘failed_reason_code’ parameter and their corresponding meanings. Failed reason codes are mappings of the codes Skrill receives from external processors and any failures due to internal procedures.

Error Description
1 Referred by Card Issuer
2 Invalid Merchant
3 Pick up Card
4 Declined by Card Issuer
5 Insufficient funds
6 Transaction failed
7 Incorrect PIN
8 PIN tries exceed - card blocked
9 Invalid Transaction
10 Transaction frequency limit exceeded
11 Invalid Amount/ Amount too high /Limit Exceeded
12 Invalid credit card or bank account
13 Invalid Card Issuer
15 Duplicate transaction
19 Retry transaction
24 Card expired
27 Requested function not available
28 Lost/Stolen card
30 Format Failure
32 Card Security Code (CVV2/CVC2) Check Failed
34 Illegal Transaction
37 Card restricted by Card Issuer
38 Security Violation
42 Card blocked by Card Issuer
44 Card Issuing Bank or Network is not available
45 Processing error - card type is not processed by the authorization centre
51 System error
58 Transaction not permitted by acquirer
63 Transaction not permitted to cardholder
67 BitPay session expired
70 Customer failed 3DS verification
80 Fraud rules declined
Code Description
98 Error in communication with provider
99 Other
Did you find this page useful?