Copy page

Integration flows

Paysafecard via Skrill: Customer Journey

This page follows a Paysafecard deposit from the customer's first click to the money being confirmed and names who does what at each step. It is the companion to Accept an Alternative Payment, which has the request and response details for every call mentioned here.

Paysafecard (psc) is reached through a hosted checkout run by Skrill. Your integration never sees the voucher. You open a payment session, send the customer to checkout_url and wait for the gateway to tell you the outcome.

Who is involved

Party	Role in the flow
Customer	Picks Paysafecard on your site and pays on paysafecard's page with their voucher PIN.
You (the merchant)	Create the payment session, redirect the customer to checkout_url and act on the outcome the gateway reports.
Softlemon gateway	Opens the session with Skrill, receives Skrill's server-to-server notification, verifies it and updates the transaction. Delivers your webhooks and answers status calls.
Skrill Quick Checkout	The hosted checkout behind checkout_url. Sends the customer on to paysafecard, receives the outcome and notifies the gateway.
Paysafecard	The voucher scheme. Takes the voucher PIN on its own page and approves or declines the payment.

The journey at a glance

The browser return and the webhook can arrive in either order. The browser landing on your site is never the signal to credit the customer. The webhook, or a status call, is.

Step by step

1. The customer chooses Paysafecard. On your deposit page the customer picks Paysafecard and enters the amount. Nothing is collected from them on your site.
2. You create a payment session. Call POST /api/v1/payment-sessions with the amount, currency, your reference, payment_method: "psc", your success_url and cancel_url and the customer's email, country_code and ip_address. Send customer.email on every Paysafecard session. Skrill uses it to take the customer straight to paysafecard's page. Without it the customer first sees Skrill's own checkout form, enters their email there and clicks through to paysafecard. The response is pending_redirect with a checkout_url. Details are in Step 1 of the alternative payment guide.
3. You redirect the customer. Send the browser to checkout_url. This is a full page redirect to Skrill's hosted checkout, not an iframe. The session is valid for 15 minutes.
4. The customer pays on paysafecard's page. Skrill sends the browser straight on to paysafecard, where the customer enters their voucher PIN and confirms. Paysafecard authorises or declines the payment and the customer is shown the result. If the session had no customer.email, Skrill shows its checkout form first and the customer reaches paysafecard from there.
5. The customer comes back to your site. After the hosted page the browser lands on your success_url or cancel_url. Treat this as navigation only and show a waiting state until the outcome is confirmed. See Step 3.
6. Skrill notifies the gateway. Skrill sends the outcome to Softlemon server-to-server. The gateway checks the notification's signature and compares the paid amount and currency with the session before it changes anything. A notification that does not verify is held for review and the transaction is left as it was.
7. You learn the outcome. The transaction moves to captured, failed or cancelled and the matching webhook is delivered to your endpoint. You can also poll GET /api/v1/payment-sessions/{id} or the transaction. Credit the customer only on transaction.captured or a status read that shows captured. See Step 4.

What each outcome looks like

What happened	Session status	Transaction status	Webhook
Paysafecard approved the payment.	paid	captured	transaction.captured
Skrill reported the payment as still in progress.	pending_provider	pending	transaction.pending (only if your endpoint subscribes to it)
Paysafecard declined the payment.	failed	failed	transaction.failed
The customer cancelled on the hosted page.	cancelled	cancelled	transaction.cancelled
The customer did not finish within 15 minutes.	expired	cancelled	transaction.cancelled
Skrill reported a chargeback on a paid deposit.	chargeback	chargeback	transaction.chargeback

The full session lifecycle is in transaction statuses. Webhook payloads, signatures and retries are in the webhooks reference.

What to rely on

• The webhook or a status read, never the browser. The customer can close the tab, land on success_url before the gateway has heard from Skrill or land on cancel_url for a payment that later succeeds. Only transaction.captured, or a status call showing captured, means the money is confirmed.
• A late payment can turn a cancelled transaction into a captured one. If the customer finishes on Skrill's page after the session expired, you first receive transaction.cancelled for the expiry and then transaction.captured when Skrill's notification arrives. Treat captured after cancelled on the same transaction as a successful deposit.
• Your reference is reserved while the session is live. Sending the same reference again while a session is open returns the existing session instead of creating a second one. Once the session has finished or expired you can reuse it for a genuine retry. See duplicate protection.
• Sessions expire after 15 minutes. If the customer wants to try again after that, create a new session.
• Repeated notifications are safe. If Skrill sends the same notification twice the gateway ignores the repeat, so you never see two transaction.captured events for one deposit.

Refunds

A Paysafecard deposit taken through Skrill is refunded like any other transaction with POST /api/v1/transactions/{id}/refund, in full or in part. The transaction must be captured first, so a session that never reached paid cannot be refunded. The refund is recorded as a child transaction and delivers transaction.refunded when Skrill confirms it. See the refunds guide.

Related

• Accept an Alternative Payment for the request and response details of every call above.
• Set up webhooks and the webhooks reference.
• Transaction statuses.