To assist in the construction of Checkout API requests, Reepay has just launched the Checkout Helper.
https://checkout-helper.reepay.com/
The helper provides an interactive tool to construct and test Checkout API requests before implementing them.
Cheers, Reepay
When creating a charge, recurring or subscription session it is now possible to define a payment_method_reference parameter. The payment method reference is stored on saved payment methods (e.g. card) if the session results in a saved payment method.
The payment method reference is returned in the customer_payment_method_added webhook, allowing to link the webhook to a specific session/order.
If the payment_method_reference is not defined, the session id will be used as default.
Cheers, Reepay
For credit card charges, card issuer country is now returned for get charge (https://reference.reepay.com/api/#get-charge) as source.card_country.
Card issuer country is also returned in the card object for saved payment methods. See: https://reference.reepay.com/api/#get-card
Cheers, Reepay
A custom trial period can now be defined when creating a subscription, overriding the trial setting on the subscription plan. See parameter trial_period in the create subscription operation: https://reference.reepay.com/api/#create-subscription
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'.)
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.
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.
Reepay will only support TLS 1.2 by the 7th of May 2020
It is now possible to completely delete charges in state created in the Administration and using API: https://reference.reepay.com/api/#delete-created-charge
It is now possible to define credit note lines with negative amount as long as the total refund amount is positive.
It is now possible to delete a saved card in the Administration and using API (https://reference.reepay.com/api/#delete-payment-method).
It is now possible to select the event types to receive webhooks for instead of receiving webhooks for all event types. Event types can be selected in the webhook configuration in the Administration or using the API (https://reference.reepay.com/api/#update-webhook-settings)
List of event types: https://reference.reepay.com/api/#event
Cheers, Reepay