I'm trying to use checks in the XRP ledger (https://xrpl.org/use-checks.html) from post dated checks use case where the receiver can only pull the payment after a specific date.
Anyone knows if this is possible?
This is not possible with built-in Checks functionality at present.
Depending on your use case, you may be able to use a time-held Escrow.
Alternatively, if users are willing to trust an external service, you could write an app that only creates the Check (or Payment) after a specific date.
Related
According to the documentation it should be possible to receive messages from multiple senders, but I have not been able to accomplish this.
To enable this feature, make sure you have each sender's sender ID. When requesting registration, the client app fetches the token multiple times, each time with a different sender ID in audience field, using the token retrieval method for the given platform
This was indeed possible some time ago, by specifying the sender(s) id(s) when getting the token, but it was deprecated and the current getToken() method does not accept a senderId parameter any longer.
I also tried configuring multiple projects in the app, but Firebase Messaging does not seem to support instantiating with a different project name (while Firestore, Database, etc. do).
So my question here, in the current scenario, is how am I supposed to accomplish the reception of messages from different senders. After the deprecation of the senderId parameter in getToken(), is there an official approach to this that I'm unaware of?
Alternatively, is there any other approach you would recommend?
Note: I'm working with Flutter, but according to the documentation the same limitations are valid for native Android (and iOS?)
I'd like students to be able to access the first couple of lessons in Moodle before being presented with a request for payment. I've searched for ages on Google and found nothing, and also searched for all the possible terms I could think of here, and again come up short. Apologies therefore for the lack of contributing research/evidence.
I'm using Paypal as the chosen method of payment at the moment. Moodle is version 3.2.
Is there a way to add this kind of option to the 'access restrictions' in the courses themselves?
There isn't an existing way to restrict activity access based on the users enrolment type.
Without writing some custom code, the easiest way to do this is probably to have a separate course containing the pay-walled content, with paypal enrolment set up.
Add an activity to the free course with a link to the paid course. Use access restrictions to hide it until the other activities are complete.
When a user completes the free course content, the link to the paid course will be revealed, and they can click to enrol using paypal.
I've been trying to find a way to store a piece of data relative to a customer in my store. Ideally I was hoping to be able to create a Metafield that would store a single numerical value and be retrievable by the customer's id or email.
Any thoughts or suggestions would be really appreciated. Ideally I'd like to be able to handle everything in the liquid layer by editing the html and css of the store directly. A custom app with API integration is another option but less desirable as it doesn't seem necessary and would appear to be a lot more work.
EDIT: Tried piggybacking the order (thinking orders are unique to users) but it doesn't appear that the order object is created until the checkout is complete so that isn't really useful since I want to be able to attribute the user to a session click that led them to the store.
Thanks,
Alex
You will want to use an App. First, off, that is the only way for you to alter any objects in Shopify. Secondly, you can easily store simple things like counter values on the Customer resource using metafields. Third, anything you do with metafields on the Customer would be easily visible to the customer, since you can expose those metafields using Liquid. Fourth, if you choose to use JS you must use the App Proxy pattern. Shopify will then send your JS XHR payload to your App endpoint in a secure fashion.
So your needs and how to do are not new, they are old skool in Shopify terms and very straightforward to implement.
I need to know if an installation has been paid for in the past so I can provide some premium features.
Storing a payment flag in indexeddb or the file system sounds easy to defeat. Periodically asking a server and caching the response could do the trick, but I guess the user would have to be logged-in at all times (through google or otherwise) and I'd rather not impose that restriction.
Maybe if there's a way to uniquely identify a user's machine (uuid, mac address, etc) that could allow me to determine if they've made that payment?
Ultimately, this is client side JavaScript. The only means by which you can prevent use of certain features, is to put them on your server and charge for the service.
Some weak methods for preventing access include license validation, and asking the server for non-essential information (if it was essential, then see the above).
For license validation, you could create an algorithm that takes data from the user and transforms it into something else. For example, say they create an account on your website, which your server knows is a 'pro' account. You could then take their first name and email address and do some magic on it.
Here's a simple example that takes those inputs and gives us a key. In this example if our first name is "John" and our email is "john#domain.org", then our key will be fcumnflqjpBfqockp0qtifcufLqjp. However, Tony, with the email "tony#doman.org" would recieve fcumnfvqp{Bfqockp0qtifcufVqp{
You can send this key to the user, and have your code decide whether it can extract the name and email by applying the reverse algorithm.
You can reverse the strings, do various bit math, etc. It's security by obscurity. Other than an account, this is the most common method. It's used by nearly all offline software. Its kryptonite is key generators, which reverse engineer your code, and generate keys by the algorithm you use to verify them.
All the methods such as uuid, mac address etc can be easily forged imo. I think you cannot escape keeping track of user's logged-in status. Implementing something like a cookie based mechanism would be the right way to go.
I have a C++ plug-in for MetaTrader 4 that allows me to create new accounts in it for trading purposes. I would like to be able to dictate to MT4 the account number when creating the new account. Might any one know whether this is possible and how it might be done?
The account number is generated by the broker upon account creation - So the simple answer is No; you cannot control it. The only way would be to generate an account number, and based on it anticipate what the next account number will be. This is only possible if the account number algorithm is broker-specific. This would surprise me though. I am willing to bet that account numbers are generated by MetaQuotes server with a one-way-function.
You can specify the account number in the login field of the UserRecord struct your are using in the call to UserRecordNew method. If the account already exits you will get an error from the method as apposed to RET_Ok.
If you use any API, you can manually enter the account number. If the specified account number exists, the system will reject your request. Is there any particular reason you want to enter custom numbers while opening the account?
It is not possible to control the account number. The justification of this is the fact that the account number is developed by the broker upon the opening of an account.The only way that this would be possible would be if one was to generate an account number and use this number to anticipate what the next account number will be. This approach is however, possible if the account number algorithm is broker-specific.