It is now possible to use trial for fixed day scheduling, e.g. billing on the first of every month. If trial is used the subscription will be in trial and billed at the end of the trial period. The billing at the end of the trial period depends on the configured partial period handling. If proration is used, a prorated invoice will be made for the remaining billing period until the fixed scheduling day.

As an example consider a subscription plan with billing every first of the month and a seven day trial period. If a customer signs-up on the 14th, the trial will run until the 21st where the customer will be billed prorated for the period 21st to end-of-month.

To configure trial on a plan go to: Configuration → Plans → Create/supersede → Trial.

Cheers, Reepay

If you have an API integration to Reepay, this information might be important to you.

To keep your API integration with Reepay secure, we have planned to phase out support for old technologies: SHA-1, TLS 1.0, and TLS 1.1. (These protocols and TLS 1.2 power the 'Secure' in 'HTTPS'.)

Why

SHA-1 is one of the algorithms you can use to authenticate who you’re talking to. It’s now considered dangerously weak, and might allow an adversary to spoof their identity. This is why all modern browsers have stopped accepting SHA-1 certificates.

TLS 1.0 and 1.1 ensure that your communications stay private. In order to do this, they generate a series of random bytes used to encrypt your connection. TLS 1.0 provides two ways of doing this (CBC and RC4), but several vulnerabilities have been discovered in both of them (including BEAST and the RC4 biases). If you kept using old versions of TLS, someone could theoretically sniff your connection.

As a result the internet is moving towards SHA-2 and TLS 1.2. These technologies have few known attacks and were subject to more rigorous security design than their predecessors.

What this means to you

The upgrade process will be seamless for most users. Most frameworks and operating systems support TLS 1.2 out of the box without any changes required, but older clients might be affected, e.g. Java 6. To test if your client supports TLS 1.2, you can make a test HTTPS GET request for the following url:

https://sandbox.reepay.com/api/helloworld

If your client supports TLS 1.2 you will receive the a text response with content Hello world. Otherwise an error will be raised by the client.

If your client does not support TLS 1.2, you will need to make the necessary upgrades to your environment.

Don't hesitate to contact us at support@reepay.com if you have any questions.

Timeline

Reepay will only support TLS 1.2 by the 7th of May 2020

We have updated our PrestaShop plugin! It's important you upgrade to the newest version. Here is why:

- Get notifications directly in the PrestaShop admin every time the Reepay PrestaShop Plugin can be updated

- Improved usability in Reepay PrestaShop Plugin settings

See also our new PrestaShop landing page and guide here: https://reepay.com/prestashop-plugin/

We have updated our WooCommerce plugin!

Now you can:

- Create manual orders in your WooCommerce backend (one-time and recurring)

- Show ApplePay logo in the proceed to checkout window

- Support PDF Product Vouchers

Fix:

- Settle problems with WooCommerce Subscriptions

PDF Product Vouchers: https://woocommerce.com/products/pdf-product-vouchers/

We now support one of the best payment methods for fast checkout and better conversion.

Apple Pay is a mobile payment and digital wallet service by Apple Inc. that allows users to pay online and in person. With our new integration for Apple Pay, you can increase your conversion by offering the extremely simplified payment experience, that Apple Pay provides.

We do not charge you any additional cost for the use og Apple Pay. You only pay your existing payment gateway and acquiring fees.

Activate Apple Pay today by logging in to your Reepay Dashboard and follow this guide: https://intercom.help/reepay/en/articles/3328290-how-to-configure-apple-pay

Cheers, Reepay

When charging a customer, where the customer is present in the payment flow (Customer Initiated Transaction), coming PSD2 regulations require that the card holder is strongly authenticated (e.g. 3D Secure), except for some exemption cases. Read more about PSD2 here: https://blog.reepay.com/psd2-strong-customer-authentication/ This will affect the use of saved cards for easy checkouts, as the card cannot be used without Strong Customer Authentication (SCA) in the card holder present scenario.

To remedy this, Reepay Checkout now offers an option to start a checkout charge session with a saved card (card-on-file). The customer will be sent directly to Strong Customer Authentication and directly back afterwards with success or error indication. In some cases SCA is not necessary, so the customer will not be prompted with any request for information during the payment session. See: https://docs.reepay.com/reference#card-on-file

Notice that Merchant Initiated Transactions, that is payments initiated by the merchant (or a party acting on behalf of the merchant - e.g. Reepay), where the customer is not present in the payment flow, are out-of-scope for SCA. In this scenario payments with saved cards can still be performed using the Charge API (https://reference.reepay.com/api/#charge).

Cheers, Reepay

Reepay now supports PayPal as a payment method for one-off payments.

According to several surveys, 59% of PayPal users have abandoned a transaction because PayPal wasn’t there.

Businesses can establish trust with consumers by offering preferred payment methods; 44% are more likely to trust and shop with businesses with a preferred payment provider and good payments process.

To setup PayPal follow this help article: https://intercom.help/reepay/en/articles/3315950-how-to-configure-paypal

Cheers, Reepay

In preparation for the coming PSD2 regulatory changes (September 14th), Reepay hosted pages and Reepay Token now supports Strong Customer Authentication (SCA) (3D Secure and Dankort Secured by Nets).

No action is required by you as a merchant. SCA will be enabled by us for all merchants, not already using SCA for Checkout, before September 14th.

Dunning plans can now be configured with an optional grace period before the dunning process starts. During the grace period retrying will be performed if the payment method has suffered a potentially recoverable soft decline, e.g. insufficient funds. It can be configured if dunning should start immediately for irrecoverable hard declines, e.g. expired credit card.

The grace period can be configured for dunning plans in the Administration: Configuration → Dunning Management

Cheers, Reepay

User groups in the administration have been changed to better accommodate for the needs of our customers. The new user groups are more intuitive as they more closely relates to the functionality accessible in the left menu. It is also possible to define more fine grained permissions, e.g. whether specifically refunding is allowed. The screendump below shows the new user group edit dialog.