VulCode

PayU integration through the REST API

Orders, notifications, refunds, saved cards and BLIK on your own page, built on REST API 2.1. For stores and apps where a ready plugin cannot handle the way you sell.

Payment gateway comparison
A store panel: PayU payments waiting to be captured, with a stock check and the decision for order 10524

How we build a PayU integration

The six most common situations and how we build the PayU integration in each.

If you are starting a new PayU integration,

PayU's current API

then we build it on PayU's current API. The older Classic protocol is no longer open to new integrations, so nothing will need rewriting.

If the customer pays without an account in your store,

A plain payment

then the integration connects to PayU with your point of sale's key and renews its access before it expires, so payments never stop mid-day.

If the customer is signed in and pays with a saved card,

A saved card

then we link the card to their account in your store. PayU has to enable saved cards, so we check that before quoting.

If payment has to be part of a panel, app or booking,

Your own integration

then we write an integration that fits the way you sell, with BLIK and cards on your own page and no redirect. A ready plugin cannot do that. The gateway comparison

If a customer returns part of an order,

A refund from the panel

then you order a partial refund in your panel. The panel shows how much is still refundable, because refunds cannot add up to more than the order.

If you want to test first,

Tests before launch

then we start in the PayU test environment, and a public test point of sale covers the first tries. We run heavy-traffic tests on our side, because the PayU test environment is not meant for them.

From the cart to a paid order

The simplest flow, with a redirect to the PayU payment page.

  1. Your server

    connects with the point of sale's key

    At the start
    order 10517

  2. The order in PayU

    amount, products, the notification address and the return page

    From step 1
    creates the order

  3. Payment page

    the customer picks a method and pays

    From step 2
    the payment link

  4. Notification

    signed, sent to the address given in the order

    From step 3
    status change

  5. Status in your system

    after checking the signature and amount

    From step 4
    receipt confirmed

  • When it works

    COMPLETED: the payment is accepted and we start fulfilling the order.

  • Held for a person to check

    From step 4: the signature or amount does not match

    The order keeps its status, and a notification without a matching signature is turned away.

  • When it fails

    CANCELED: the payment is cancelled and the buyer was not charged. The order goes back to payment or expires.

Confirmed or resent

PayU waits for your server to confirm it got the notification. Without that it sends it again on its schedule, so no payment is lost.

Paid stays paid

Once a payment is accepted (COMPLETED), further notifications about the same order no longer change its state.

Manual capture

A payment can wait until your system captures or cancels it, for example after a stock check. Without a decision PayU cancels it after the time set for the payment method.

A checked signature

We check every notification with your point of sale's second key before doing anything with it, so a forged notification never changes an order's status.

How long PayU keeps resending notifications

When your server does not confirm a notification, PayU sends it again. The schedule spans three days.

20 attempts within 72 hours of the first send
Attempts 1 to 6Resent after: immediately, 1, 2, 5, 10 and 30 minutes
a failed attempt: the store's queue was downthe sixth attempt accepted

What our module does: A short server outage loses no payment; the queue takes the notice on the next attempt.

Attempts 7 to 12Resent after: 1, 2, 3, 6, 9 and 12 hours

What our module does: Monitoring flags the unresponsive notification address before a customer notices.

Attempts 13 to 20Resent after: 15, 18, 21, 24, 36, 48, 60 and 72 hours

What our module does: Orders without confirmation go on a list, and we check them by fetching the transaction data straight from PayU.

The PayU notification log in a store panel: order 10517 accepted on the sixth attempt, after five failed ones

Four ways to take payment through PayU

From a redirect to a card saved on the customer's account. We roll out each of them and match them to how much should happen on your own page.

FeaturePayU payment pageredirectBLIK on your pagecode entered in the shopCard via Secure Formcard fields from PayUSaved cardon the customer's account
The customer stays on your pagePayU payment pagenoon the PayU pageBLIK on your pageyesin your form and the banking appCard via Secure Formyesin PayU fields embedded in your pageSaved cardyesin one click on the next purchase
Card data bypasses your serverPayU payment pageyesBLIK on your pageyesCard via Secure FormyesSaved cardyes
Works without extra PayU configurationPayU payment pageyesBLIK on your pagepartlyCard via Secure FormyesSaved cardnoPayU has to enable saved cards, and some older points of sale do not have them.
Works without a customer accountPayU payment pageyesBLIK on your pageyesCard via Secure FormyesSaved cardnoA saved card is linked to the customer's account.
Good forPayU payment pageA quick start and many methods at onceBLIK on your pagePhone purchases without leaving the shopCard via Secure FormCard payments with no redirectSaved cardStores with returning customers

Your order, the PayU order

This is how we join the data so every notification reaches the right order.

Your system
order 10517
Rule on the way
PayU
the same order in PayU
  1. Your systemorder number 10517
    →unique, ties notifications to the order
    PayUthe order identifier in PayU
  2. Your systemorder total 210.00 PLN
    →PayU counts in grosze
    PayUan amount of 21000 grosze
  3. Your systemcart lines
    →unit prices in grosze
    PayUproducts with price and quantity
  4. Your systemcustomer email
    →PayU sends its confirmation there
    PayUbuyer email
  5. Your systemcustomer IP
    →required when creating the order
    PayUbuyer IP
  6. Your systemnotification handler address
    →can differ for each payment
    PayUnotification address
  7. Your systempage after payment
    →for the customer only, confirms nothing
    PayUreturn page
WhatDirectionWhen
The orderYour system → PayUWhen the customer clicks "Pay". The reply carries the link to the payment page.
A status notificationPayU → Your systemAfter every status change, signed. We check the signature before the order changes.
The customer coming backPayU → Your systemAfter paying. It is a page for the customer and confirms nothing.

Common questions about PayU

Answers about cards, saved cards, notifications, capture, refunds and the quote.

How do your customers pay today?

Tell us where PayU payments should work and what should happen after payment. We will reply within an hour with questions and a quote.